This is why I think the biggest win for memory would be having XS based
time zones. This would also help speed somewhat, but I think the memory
savings could be very, very substantial.
If you look at the compiled Olson DB bits used by libc, they're fairly
small binary files (<1-2k usually). I think it'd be possible to get the
DT::TimeZone stuff down to around this size per zone if we could use C
structs and XS, rather than simply using XS to manipulate Perl data
structures (which is faster but saves no memory).
There was a discussion on this list a while back about doing this, and it's
something I'd still really like to see one day. We develop an email
web-interface with users from around the world who can select their timezone
to display emails dates correctly.
Currently we have to use something that feels really hacky...
sub TZToSeconds {
my $TZName = shift;
my ($t, $gmt);
{
local $ENV{TZ} = $TZName;
tzset();
$gmt = time;
$t = timegm(localtime($gmt));
}
return $t - $gmt;
}
We had tried to use something like:
return DateTime::TimeZone->new(name =>
$TZName)->offset_for_datetime(DateTime->now());
But pre-loading all the timezones at startup took a considerable number of
seconds and almost 15M of memory.
It's actually an interesting tradeoff. We wanted to use timezones so that
there was automatic daylight savings changeovers for users, but we didn't
care enough to use full date arithmetic on each date (eg dates before/after
the DST changeover). This was a good performance compromise, in that we just
get a seconds offset for the *current datetime*, and add that to all
datetimes. This means at a DST change over, all emails before the actual
changeover show the wrong datetime by 1 hour, but almost no one ever
notices, they only really care about the datetime on the very newest emails,
which are correct.
Anyway, I think the main things that would be really nice are:
1. Store the timezone data in C structures or in some easy to access DB
format (CDB or TDB?) to reduce the memory footprint size, and the load time.
2. Just store a list of timezones in some perl structure
3. Have only 1 timezone class (well, not including Local/Floating/etc, 1
class for all the "standard" timezones). Do all the separate timezone
classes actually contain any code, or do they just store data? Why should
they be separate classes, rather than 1 class with different instance data
for each timezone?
Rob
