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
