I don't consider this to be completely a DateTime issue however I
thought I would share my findings to this list for consideration.
I'm using the latest release of DateTime with perl 5.8 (Standard RPM
distro) for FC4 on a very old 166MHz Pentium system. So I don't
expect this system to fast.
Using this system if I take the following two scripts:
test1
#!/usr/bin/perl
test2
#!/usr/bin/perl
use DateTime;
The performance of them is like this:
[EMAIL PROTECTED] tmp]$ time perl test1
real 0m0.060s
user 0m0.016s
sys 0m0.044s
[EMAIL PROTECTED] tmp]$ time perl test2
real 0m5.805s
user 0m5.456s
sys 0m0.284s
That to me is a huge performance hit to just load a module. This is
the distribution of where all the time for test2 is getting spent:
[EMAIL PROTECTED] tmp]$ strace -c perl test2
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
41.51 0.098303 209 471 420 open
32.34 0.076580 181 424 420 stat64
13.73 0.032522 290 112 read
3.74 0.008861 269 33 old_mmap
2.20 0.005213 57 91 3 _llseek
1.56 0.003700 73 51 close
1.08 0.002549 2549 1 execve
1.02 0.002408 62 39 36 ioctl
0.95 0.002241 93 24 brk
0.46 0.001085 121 9 mprotect
0.45 0.001054 66 16 fstat64
0.21 0.000508 508 1 readlink
0.19 0.000446 149 3 mmap2
0.13 0.000301 151 2 munmap
0.09 0.000213 213 1 _sysctl
0.08 0.000181 45 4 rt_sigaction
0.05 0.000129 129 1 1 access
0.04 0.000089 45 2 time
0.02 0.000059 59 1 futex
0.02 0.000050 50 1 fcntl64
0.02 0.000048 48 1 getrlimit
0.02 0.000044 44 1 set_thread_area
0.02 0.000042 42 1 rt_sigprocmask
0.02 0.000038 38 1 getuid32
0.02 0.000037 37 1 set_tid_address
0.02 0.000036 36 1 geteuid32
0.01 0.000035 35 1 getgid32
0.01 0.000034 34 1 getegid32
------ ----------- ----------- --------- --------- ----------------
100.00 0.236806 1295 880 total
From this the biggest time consumer is opening and stating files
followed by reading them. This also generates a lot of errors because
of how FC4 has decided to support old path's in perl's default @INC.
They include a lot of old directories that are empty but this forces
perl to search them all anyways. So with a path of about 20+
directories most empty plus DateTime loading 100+ different files
just to get started turns into a fair amount of searching and loading.
One might hope that a script like this:
test3
#!/usr/bin/perl
BEGIN {
no lib qw|/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/
lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/
site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/
5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6 /usr/lib/
perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/
site_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/
5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-
linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-
multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/
lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/
perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/
perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-thread-multi /usr/
lib/perl5/5.8.6 .|;
use lib qw|/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /
usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/
vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/
5.8.6 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-
thread-multi /usr/lib/perl5/5.8.6 .|;
}
use DateTime;
Might improve the situation. However even this has no significant
improvement and from additional traces it doesn't actually stop perl
from using the built in paths.
[EMAIL PROTECTED] tmp]$ time perl test3
real 0m5.721s
user 0m5.424s
sys 0m0.216s
Not that I expect anyone to fix anything about this but I just
thought I would pass it along. On most fast computers today this
busy work probably isn't noticed as a delay but on this box 5 sec
just to get started is a very noticeable delay for any command line
scripts that might include DateTime.
Matthew
