On Thursday 19 January 2006 03:05, Dave Rolsky wrote:
On Wed, 18 Jan 2006, Chase Venters wrote:
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
What is /usr/share/zoneinfo/right and how does it differ from
/usr/share/zoneinfo?
http://www.thedjbway.org/clockspeed/leapsecs.html has a bit of information...
basically (my understanding) it's a timezone with proper leap second
accounting. I have this sneaking suspicion that DateTime doesn't understand
this and is hence doing the calculation when it's already been done. (But
then again, I could be talking out of my ass - I haven't spent too much time
in the internals yet)
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.
Recurrences are not simple at all, and I'm hardly surprised that using
them things makes page rendering much slower. But without a description of
what you're trying to achieve, and how you are doing it, I can't offer any
suggestions.
Well, DateTime::Event::Recurrence is what I'm relying on, and it's pure perl.
But I think in my course of working with DateTime it's unfortunately often
felt a bit slow :(
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.
Actually, I think it has to do with the cost of passing data across the
Perl - C boundary. From what I've heard, this is somewhat costly, so the
C code has to be enough faster to really make a difference.
That said, I tried that optimization a _long_ time ago, so it might be
possible to try again.
Yeah, I figured it might have something to do with that. What are your
thoughts about a DateTime implementation that was *mostly* XS? It would be a
lot of work (though it would certainly be made easier because you've already
done the hard part of figuring out the logic, which means all a guy like me
has to do is reproduce your logic in C). I think by keeping most of the
computation in C, you'd certainly get gains well beyond the XS overhead.
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.
Daisuke Maki tried making all the DT::TZ modules use XS, and in fact went
so far as to turn them into C-based data structures that were primarily
accessed via XS. Strangely, this was also slower and more memory-intensive
than the Perl version.
Odd. It might have something to do with what we're talking about above.
I think there's a branch for this in the DateTime CVS repo. I'd love if
other folks could take a look at it and see if there is some way to make
it faster and smaller. It seems like it should be possible, so maybe
there's some obvious fix that Daisuke and I missed.
Other than that, I don't know that the DateTime.pm module has any obvious
problem spots, but I haven't profiled it either, so I'm pretty much
talking out my rump.
Welp, I'm unfortunately quite preoccupied with a project at the moment, but I
consider DateTime to be a vital piece of my CPAN arsenal for web / tel app
development, so I'm more than willing to put in time when I can.
Thanks for your response!
-dave
Cheers,
Chase