Olivier Mengué (dolmen)

Dist::Zilla is slooooowww!

This is in part because it uses Moose. In part because it has many features. In part because it uses App::Cmd that has a major design issue (it loads all command plugins on every run).

But this is also because most plugins are written without care for their compile time and run time cost especially when they are loaded but not used. For example the BeforeRelease plugins when you just run dzil test.

Despites this I'm using it every day at work (because it is powerful), but with much pain.

So here are some tips on how to contribute to improve that situation.

The first rule for plugins authors is to load runtime dependencies only at runtime. Not at compile time. For example, if a plugin needs App::Prove, it must not load it with:

use App::Prove 3.00;

Instead you have to load it at runtime when it is really used:

require App::Prove;
App::Prove->VERSION('3.00');

App::Prove->new(...);

I have already fixed most of the plugins bundled in the Dist::Zilla core by submitting patches, and I have submitted RT tickets and patches to a bunch of other plugins from the CPAN.

perl -d:TraceUse -S dzil nop 2>traceuse.txt

You'll get a 600 lines file that lists all the perl files loaded as a tree that tells you who required it first. So you can easily find the Dist::Zilla::Plugin::* or Dist::Zilla::App::Command::* module that loads too much things.

For more advanced dzil profiling tips, check this gist.

So this is a call for help to fix all the dzil plugins! Submit tickets and send pull requests to plugins maintainers!

PS: when I started to use Dist::Zilla I immediately tried to workaround the issue with my own tool Dist::Zilla::Shell, in hope to reduce that load time cost. Unfortunately it is quite experimental (I've seen some issues due to caching somewhere of PPI documents), but I would appreciate feedback and bug reports.