Re: DateTime::Lite

>> A lot of times you don't even need to do date time arithmetic, for
>> example. These methods are separated out onto a different file, so you
>> need to load it on demand.
>>
>>    use DateTime::Lite qw(Arithmetic);
>>    use DateTime::Lite qw(Strftime);
> 
> Have you actually benchmarked the memory usage and compile speed for 
> this stuff? I have a hard time imagining it really is all that slow, 
> since it amounts to a few methods in each case.

Yes, I wrote a crude benchmark script in 
DateTime-Lite/tools/benchmar/load_times.pl
If you don't load arithmetic and strftime, DT::Lite is twice as fast 
plain DT.

                Rate           dt dt_lite_full      dt_lite
dt           46.6/s           --         -13%         -49%
dt_lite_full 53.7/s          15%           --         -41%
dt_lite      91.7/s          97%          71%           --


And again, /I know/ this isn't that much of a practical problem, because 
the engineer's correct answer is "if the load time is slow, load it 
once, and use some sort of persistent environment". This is mainly a 
marketing issue to my audience, who, for example, includes CGI 
developers (i.e., persistent environment isn't an option).

BTW, dt_lite_full is almost equivalent to using DateTime.pm, but I 
/think/ the difference comes from the tweak I did to switch method calls 
to function calls. That can probably be tweaked in DateTime.pm, if you 
want me to apply it.

> 
>> Singletons are okay, they serve a particular purpose. But besides being
>> a memory hog of relative low benefit, when given the number of time
>> zones are locales, they are just way too overwhelming for underlings.
> 
> Could you explain this? What are you doing instead of singletons? Do you 
> reload the time zone every time it's asked for?
> 
> Also, that second sentence makes no sense ;)

No, it's cached in memory, so in that sense they are "singletons". 
However, they are all instances of the same DT::Lite::TimeZone object.
When asked to load a time zone, I'm just require()ing a plain perl file, 
and shoving them to the constructor of DT::Lite::TimeZone. The timezone 
created is stored in a hash.

Creating GVs for each timezone is a waste. Creating one class, then 
creating instances for each timezones are much cheaper. I discussed this 
briefly when I was trying to do DateTime::TimeZone::XS, but I got warnocked.

>> With this version, the objects are mostly the just plain objects, and
>> the exact definition for each timezone/locale is stored in data files.
> 
> What do the data files look like? If using them is faster than the 
> current DT::TZ implementation, is there any reason we can't switch 
> DT::TZ to use it?

I don't think DT::TZ will benefit anything from using my method, as they 
are true singletons. the data format isn't going to change anything.

I'm not saying DT::TZ needs to change, either. If you want singletons 
that's just fine, but one of my requirements is to reduce the number of 
classes that needs to be installed.

Again, /I know/ that installing data files instead of classes isn't any 
better, but I'd like to have a way to pick and choose which time zones 
the user wants to use/install, so they have the illusion of control over 
how much stuff is required to run DT::Lite.



--d