Speed up load time of autodie

[schwern]

autodie accounts for almost half our startup time. Speeding up its load time would greatly increase performance.

Caching wrapping the core functions might be one way to go.

[notbenh]

Is this still an issue? If so do we have any ideas on what can be done here?

[schwern]

Feed @pfenwick caffeine and sugar.

I poked him about this in rt.cpan.org #46984 and there's some detail in there about how performance might be improved. Its 4 years old, so it would have to be re-profiled, but there's some low hanging startup performance fruit in there.

The performance numbers I have say we load in 145ms without autodie and 195ms with. Its not half, but a quarter isn't great either.

Somewhere on my todo list is to implement autodie in the C code of Perl itself, but don't hold your breath.

[pjf]

I would love autodie in C. <3

Autodie has a pretty bitchin' test suite. If you have any changes which improve speed and have the test suite still pass, then I'm super interested in them. Although all the speed improvements seem to be in the scary bits of code which make my head hurt.

[nthykier]

Hey,

The last remarks on this issue seems to be before the release of autodie 2.18, which should have taken 40-50% off its start up time of autodie. I also submitted a patch series for autodie to reduce it by another factor 4 (see Dual-Life/autodie#28, yet to be reviewed). Not sure there is much to do on the perl5i side of this, but we can improve things on the autodie side.

The rewrite in C might be a really good idea as XS subs are invisible in caller (see Dual-Life/autodie#32). But to be honest, I am not sure what can be done on the "perl5i" side for improving the load time of autodie. :)

~Niels

[nthykier]

For reference, the load times of perl5i::2 (v2.13.0 with autodie v2.26) and autodie (v2.26) today are:

pragma	used once	used 1000 times (eval included)
perl5i (autodie v2.26)	0.20s (5/s)	36.6s (27.3/s)
autodie (v2.26)	0.04s (25/s)	3.2s (312.5/s)
strict	0.005s (200/s)	0.04s (25k/s)

It should be noted that for subsequent uses of autodie, the average load time of autodie drops to slightly under 0.004s a piece (happens at v2.21 as I recall). It is still miles from "strict" which is extremly fast in comparison (even including the eval)[1].

I agree that autodie is certainly one of the "heavy ones" for one-liners (20% of perl5i's load time). However, for a ~80 modules all using perl5i::2, the load time spent in perl5i (and submodules) will be just shy of 3 seconds. Of which, autodie will be claiming "only" 0.36 seconds (~12-13%). In my opinion, it might make sense to start looking at other things to optimise.

Method
For "once" I used, time perl -M -e '' (rounded). For the "1000 times" run, I used time perl on the following script:

#!/usr/bin/perl
use strict;
use warnings;
use constant N => 1000;

# Pretend we are a project with a N modules that all use <module>.
my $str = join("\n", map { "package A$_;\nuse <module>;\n" } (1..N));
eval $str;
die $@ if $@;

Caveat: This test can consume an obscene amount of RAM. In particular, I am not able to run this using perl5i::2 with autodie v2.15 without fearing it will take down my system. Just testing autodie v2.15 alone, causes the perl (with N=1000) to pass the 2 GB mark (compared with autodie v2.26 which stays under 200MB). With autodie v2.18 (first version with optimisations) cut this in half.

[1] In fact, for the "once" case, a raw "perl -e ''" have about the same run time.

[schwern]

The numbers I'm getting now agree, use perl5i::2 and use perl5i::2 -skip => ["autodie"] differ in load time by only about 5-10% with autodie 2.26. So I'll close this up.

I have been working on implementing autodie as a core feature. It works and shouldn't be hard to finish. It is much faster and more reliable and simpler. The complication is fully emulating all the ways autodie can be customized and overloaded. To avoid this, I have decided to give up on emulating autodie exactly and implement it as a new feature "exceptions". But you may wish to take a crack at it. Details here.