Re: DateTime performance
On Mon, Jan 16, 2006 at 06:21:54PM -0800, [EMAIL PROTECTED] wrote: 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. Then no lib isn't doing what you want. Try just: BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC }
Re: DateTime performance
On Wed, Jan 18, 2006 at 08:38:13AM -0800, [EMAIL PROTECTED] wrote: Then no lib isn't doing what you want. Agree. But, that is the point. Outside of recompiling perl with new paths or significantly altering DateTime to use far fewer dependancies nothing can really be done. test4 #!/usr/bin/perl BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC } use DateTime; Do your traces show it still searching all the removed paths? There's no way the above should be doing that, unless you're loading DateTime earlier, via sitecustomize.pl or $PERL5OPT?
Re: DateTime performance
Then no lib isn't doing what you want. Agree. But, that is the point. Outside of recompiling perl with new paths or significantly altering DateTime to use far fewer dependancies nothing can really be done. test4 #!/usr/bin/perl BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC } use DateTime; [EMAIL PROTECTED] tmp]$ time perl test4 real0m5.780s user0m5.524s sys 0m0.188s Matthew
Re: DateTime performance
Do your traces show it still searching all the removed paths? yes There's no way the above should be doing that, unless you're loading DateTime earlier, via sitecustomize.pl or $PERL5OPT? Neither of the items you have identified are used in any way during these tests. I would expect if either of those had been the issue then even test1 would be slow. Regards, Matthew
XS Leap second questions
Greetings fellow Perl hackers, I'm attracted to DateTime's very comprehensive approach at dealing with time (which I personally consider to be one of the biggest annoyances and challenges in programming). Unfortunately, I've been plagued by an oddity in the way DateTime handles leap seconds in face of the Olson timezone database for some time. This shows up as test failures: t/04epoch...NOK 12# Failed test (t/04epoch.t at line 40) # got: '997120978' # expected: '997121000' t/04epoch...NOK 14# Failed test (t/04epoch.t at line 43) # got: '2' # expected: '3' t/04epoch...NOK 20# Failed test (t/04epoch.t at line 81) # got: '1049160580' # expected: '1049160602' t/04epoch...NOK 22# Failed test (t/04epoch.t at line 84) # got: '29' # expected: '30' t/04epoch...NOK 24# Failed test (t/04epoch.t at line 90) # got: '1049167780' # expected: '1049167802' t/04epoch...ok 32/32# Looks like you failed 5 tests of 32. t/04epoch...dubious This happens when /etc/localtime is linked to a timezone in /usr/share/zoneinfo/right as opposed to /usr/share/zoneinfo. The problem bites me in the ass, unfortunately, because I tend to store date / time values in SQL as an epoch rather than a native type (less back and forth conversion required). This can result in my events drifting 22 seconds, etc. Also, it's been clear to me that using DateTime heavily is a good way to quickly kill performance. Pages that took 20ms to render jump to 500ms when I try to do something simple like apply a recurrence set to a month. I started peering into DateTime internals and have noticed that the xs seems a little... lite? Curiously, I read the text supplied with the distribution and noticed this: NOTE TO FUTURE DEVELOPERS: Attempting to implement add_duration in XS actually seemed to slow date math operations down. Sad but true. Curious - what was the strategy? What do you assume to be the bottleneck? C has *got* to be faster at math than Perl, so I have a feeling the above remark is specific to a particular implementation approach. Along those lines, are there any known outstanding areas where DateTime could use some optimization? I'm handy with C, very handy with Perl and somewhat capable with XS... I'd like to help. Thanks, Chase Venters