A new version of Dancer has been published to CPAN a few minutes ago, it’s also available from the official website, in the download section.

As you can see, the project has now its own domain name: http://perldancer.org, it’s clearly more shiny than the previous subdomain I used ;) So feel free to update your bookmarks (even though the old domain name now redirects to the new one).

Oh, and there is also a mailing list now, for people who like to share experiences about Dancer; feel free to join.

The change set for 1.160 is impressive, thanks a lot to everybody who got involved!

Happy dancing.

I recently focused on Dancer’s core with a single target in mind: optimization.
After having heavily refactored the Dancer::Route class, I started benchmarking Dancer.

To start with, I’ve created a set of test applications, in order to bench different kinds of application (from a hello world app to a huge one).

All these applications are available in this repository, if you like to see more precisely what I did.

The first test I did was to bench a “hello-world” application, with PSGI, Dancer 1.150 and the last version of the master branch.

hello.psgi .................... 1420 req/s
hello.dancer (1.150) .......... 1260 req/s
hello.dancer (github/master) .. 1320 req/s

You can see that Dancer “master” is about 100 req/s faster than 1.150, this is mainly thanks to Dancer::Route::Builder: Dancer now compiles all the routes defined by the application at startup time, and don’t spend time whenever a request is handled to do that job.

Moreover, thanks to SawyerX, Dancer now caches route resolution via Dancer::Route::Cache, and that increases response-time drastically when accessing an application with lots of routes.

Here is another bench that I did against an application with 676 routes handlers.

big.dancer (1.150, no cache, no route compiler) ...  110 req/s
big.dancer (GH, no cache, route compiler) .........  130 req/s
big.dancer (GH, cache, route compiler) ............ 1300 req/s

It appears clearly here that with a big number of route handlers, Dancer’s response-time decreases. I wanted to see more precisely how that occurs, and I run a bench in order to compare the response-time when varying the number of route hanlders.

As you can see on this graph, thanks to route caching, we now have a roughly constant response-time, no matter how many route handlers we have in the applicaiton.

These improvements will be shipped with the next CPAN version, either 1.151 or 1.160 if we have the time to add some new features as well.

Stay tuned.