On Sun, 3 Aug 2003, John Siracusa wrote:

> CGI->new(''):  5 wallclock secs @ 1869.16/s
>    (5.25 usr +  0.10 sys =  5.35 CPU)

CGI's constructor really doesn't do much at all, especially if there's no
query string or form submission to handle.

> Date::Simple->new('2003-01-01'):  2 wallclock secs @ 4273.50/s
>    (2.31 usr +  0.03 sys =  2.34 CPU)

This also doesn't really do much of anything.

> # "..." includes args: year, month, day, hour, minute, second
> DateTime->new(...): 16 wallclock secs @ 687.29/s
>    (14.48 usr +  0.07 sys = 14.55 CPU)

This does a lot of work, including calculating both UTC & local times,
which involves calculating leap seconds, etc.

> DateTime->now(): 21 wallclock secs @ 547.95/s
>    (18.13 usr +  0.12 sys = 18.25 CPU)

Ditto.

> DateTime does well against Date::Manip, but not so well against even a
> "big" module like CGI.  But for object creation alone, should it really
> be ~5x as slow as Date::Simple?

Yeah, probably.

> Total Elapsed Time = 19.91729 Seconds
>    User+System Time = 14.60729 Seconds
> Exclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>   27.6   4.035  4.685  20274   0.0002 0.0002  Params::Validate::_validate
>   24.0   3.510 17.549  10000   0.0004 0.0018  DateTime::new
>   18.9   2.770  3.809  10001   0.0003 0.0004
> DateTime::Locale::_load_class_from_id

This seems quite odd.  It really doesn't do much.

>   8.96   1.309  2.647  10020   0.0001 0.0003  DateTime::TimeZone::BEGIN

And this is completely mystifying.  Can you show us your code?

> These numbers confuse me a bit, because I'm only creating about 30
> Widget objects in my mod_perl request, not 10,000.  But I see a very
> significant speed hit, even if I replace my entire Widget->new() call
> with a simple call to DateTime->new().  Maybe it's some sort of
> mod_perl/DateTime interaction?

No, DateTime just does a lot of stuff.

> Anyway, I don't want to get sidetracked into mod_perl stuff.  I'm not
> sure what (else) to make of the results above, other than a possible
> wish that I could "turn off" Params::Validate's validation in certain
> performance-critical situations.

You can turn it off for everything by setting the "PERL_NO_VALIDATION"
environment variable to true.  There's no way to turn it off and on at
runtime currently, though this could be added.

> So, what does everyone else think of the object creation performance
> situation?  Is it simply "good enough" to be "3x faster that
> Date::Manip::ParseDate()"?  Are there any obvious areas that I should
> consider before I start mucking around with DateTime::new()?

Considering that up til now my concern has been primarily on getting
things correct, I wouldn't worry about it.  There are definitely some big
performance improvements possible.  One possibility is to move the leap
second bits into the DateTime XS code, which should help a lot.  The
timezone stuff can also benefit from being rewritten as XS, but that won't
help the particular cases you benchmarked, since the UTC and floating time
zones are quite fast already.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Reply via email to