Bug #44205 for DateTime-TimeZone: cache for DateTime::TimeZone::Local::Unix->

Mon Mar 16 13:03:13 2009 FANY [...] cpan.org - Ticket created

CC:	10012664 [...] ticket.noris.net

Since determining the local timezone can be quite expensive when _FindMatchingZoneinfoFile() comes into effect and scans a whole bunch of files under /usr/share/zoneinfo/, I think it would be a good idea to cache it's result on a per-process basis, e.g. by adding something like... use Memoize qw(memoize); memoize('_FindMatchingZoneinfoFile'); ... to DateTime::TimeZone::Local::Unix, or alternatively use the patch attached, which does not require Memoize. I stumbled over this when debugging performance problems of a report generator which calls DateTime->new( time_zone => 'local', [...] ) repeatedly; since we use a pre-created DateTime::TimeZone object, the program only takes a fraction of the time to run than before. Regards, fany

Subject:

DateTime-TimeZone-Local-Unix.patch

--- lib/DateTime/TimeZone/Local/Unix.pm 2009-01-21 21:47:30.000000000 +0100 +++ /usr/local/lib/perl5/site_perl/5.10.0/DateTime/TimeZone/Local/Unix.pm 2009-03-16 17:59:52.477395047 +0100 @@ -73,11 +73,18 @@ } # for systems where /etc/localtime is a copy of a zoneinfo file +{ +my %tz_cache; + sub _FindMatchingZoneinfoFile { my $class = shift; my $file_to_match = shift; + if ( defined( my $cached_tz = $tz_cache{$class}{$file_to_match} ) ) { + return $cached_tz; + } + return unless -d '/usr/share/zoneinfo'; require File::Basename; @@ -122,10 +129,12 @@ if ($@) { - return $real_name if ref $@ && $@->{found}; + return $tz_cache{$class}{$file_to_match} = $real_name + if ref $@ && $@->{found}; die $@; } } +} sub FromEtcTimezone {

Mon Mar 16 13:04:52 2009 FANY [...] cpan.org - Reminder 'performance issues in DateTime::TimeZone::Local::Unix' added

Mon Mar 16 13:06:38 2009 FANY [...] cpan.org - Subject changed from (no value) to 'cache for DateTime::TimeZone::Local::Unix->_FindMatchingZoneinfoFile()'

Mon Mar 16 13:12:35 2009 autarch [...] urth.org - Correspondence added

Subject:	Re: [rt.cpan.org #44205]
Date:	Mon, 16 Mar 2009 12:12:21 -0500 (CDT)
To:	FANY via RT <bug-DateTime-TimeZone [...] rt.cpan.org>
From:	Dave Rolsky <autarch [...] urth.org>

On Mon, 16 Mar 2009, FANY via RT wrote: Show quoted text

> Since determining the local timezone can be quite expensive when > _FindMatchingZoneinfoFile() comes into effect and scans a whole bunch of > files under /usr/share/zoneinfo/, I think it would be a good idea to > cache it's result on a per-process basis, e.g. by adding something like... > use Memoize qw(memoize); > memoize('_FindMatchingZoneinfoFile'); > > ... to DateTime::TimeZone::Local::Unix, or alternatively use the patch > attached, which does not require Memoize. > > I stumbled over this when debugging performance problems of a report > generator which calls DateTime->new( time_zone => 'local', [...] ) > repeatedly; since we use a pre-created DateTime::TimeZone object, the > program only takes a fraction of the time to run than before.

This sort of thing is a bad idea for a _module_, but easy to do you in your application. Memoizing is the kind of magic that can produce very confusing results for people using a module off CPAN. Instead, you can fetch the time zone once in some sort of globalish/singletonish/whateverish module in your app: package MyApp::Config; { my $tz; sub LocalTZ { return $tz ||= DateTime::TimeZone::Local->TimeZone(); } } -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/

Mon Mar 16 13:12:36 2009 The RT System itself - Status changed from 'new' to 'open'

Sat Mar 28 12:14:31 2009 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #44205 for DateTime-TimeZone: cache for DateTime::TimeZone::Local::Unix->_FindMatchingZoneinfoFile()

Preferred bug tracker