On Thu, 13 Nov 2003, Rob Mueller wrote:
> ./perlbloat.pl 'use DateTime::TimeZone; $TZ{$_} =
> DateTime::TimeZone->new(name => $_) for (DateTime::TimeZone::all_names)'
> use DateTime::TimeZone; $TZ{$_} = DateTime::TimeZone->new(name => $_) for
> (DateTime::TimeZone::all_names) added 12.7M
But of course you don't actually need all of those time zones. There are
quite a number of time zones that only have historical interest, for
example. Then there's the ones for various South Pacific islands, the
antarctic, etc.
So if you just loaded the ones you _needed_, it'd use a lot less memory.
> Having a look at the code, I noticed that each timezone has it's own class,
> and also a lot of data in perl structures. I'm not really sure why the
> timezone classes were developed this way, it seems fine for a simple case
> where you only need a couple of timezones, but in a case where you can
> possibly be using ANY timezone in the same script, it seems a HUGE overhead
> in memory and time to have to load all those structures into memory.
Patches welcome ;)
I'm not sure how else we could provide an accurate and complete view of
the time zone database data, other than generating Perl modules. We can't
rely on the database being present on any given system, much less being up
to date. The C-level API makes it pretty hard to reasonably do something
like convert a datetime from one zone to another, because it's all
controlled by one environment variable.
Plus that probably doesn't even work on non-Unixy/POSIXy systems.
Remember, Perl runs in a lot of places, and there's no reason these
modules shouldn't work in all of them.
> In the end, we ended up going with the POSIX timezone related calls.
> Although they're pretty hacky, they give us what we want (a seconds offset
> from GMT for a given timezone name at a particular time) in a simple, quick
> interface without needing 13M of overhead!
Right, but that's _all_ you wanted.
> We're fine using our POSIX solution now, but I thought you folks might be
> interested in this feedback - we chatted about it with Rick Measham at Perl
> Mongers yesterday and he asked if we could provide this summary. It's
> probably a good idea to keep web app developers in mind as you develop the
> DateTime namespace, since it's a place where a lot of date/time calcuations
> in Perl are required.
I do a heck of a lot of web dev, and I've used DateTime and the time zone
classes without any problems.
For example, you could just preload the time zones that your current users
are using, which would almost certainly be a small fraction of all
possible zones.
Since the time zone classes are generated, it'd be possible to generate XS
code instead of Perl. Patches or a shipment of tuits would be extremely
welcome.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
