On Thu, 13 Nov 2003, Joshua Hoblitt wrote:
Seriously, I'd like to eventually speed up/slim down the time zone stuff
but just getting it working took an enormous amount of development effort.
Making a super-fast whiz-bang version that still works is not trivial.
Maybe we should ask around
Dave Rolsky wrote:
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
On Thu, 13 Nov 2003, Matt Sisk wrote:
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.
The timezone modules use lots of spans, correct?
No, it's just a big data structure (an array
Matt Sisk wrote:
I have not verified this, but IF there is a lot of overlap of spans
between various timezones, perhaps a 'span registry' could be shared
between all the zone modules, thereby avoiding duplication of span objects.
I just ran a quick check on TZ 0.2505:
TZ module count: 367
Here's the script I used if you want to verify...
#!/usr/bin/perl
$sd = '/usr/lib/perl5/site_perl/5.8.0/DateTime/TimeZone';
my %Spans;
use File::Find;
use Data::Dumper;
-d $sd or die oops\n;
my $span_count = 0;
my $file_count = 0;
find (\wanted, $sd);
print TZ module count: $file_count\n;
On Thu, 13 Nov 2003, Matt Sisk wrote:
Matt Sisk wrote:
I have not verified this, but IF there is a lot of overlap of spans
between various timezones, perhaps a 'span registry' could be shared
between all the zone modules, thereby avoiding duplication of span objects.
I just ran a quick
Dave Rolsky wrote:
But that only applies when you load _all_ the zones How would these be
shared if you only wanted to load 10-20 zones, or even 150 zones? It
seems like the overhead of determining what is shared would outweigh the
savings.
As we saw in the beginning of this thread, there are
Now I'm starting to think we can have our cake and eat it too vis-a-vis
unique key generation for the spans.
If you don't mind, I'll take a crack at the templating in the tz module
generation script to construct the modules sharing the common data
structure.
No __DATA__ or external files will
On Thu, 13 Nov 2003, Matt Sisk wrote:
Now I'm starting to think we can have our cake and eat it too vis-a-vis
unique key generation for the spans.
If you don't mind, I'll take a crack at the templating in the tz module
generation script to construct the modules sharing the common data
I don't think the memory usage of DT::TZ is really that excessive. It's been over 3
years since I've had a sever with less then 1GB of ram in it. That's easily enough
memory for 64 x 12.5MB apache children that aren't doing page sharing.
-J
--
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
...
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
On Thu, 13 Nov 2003, Rob Mueller wrote:
The only way really to provide a fast (to initialize, and access) timezone
DB is to either provide a DB (e.g. CDB, SDBM, etc) with the module, or have
something in the make process that creates such a DB based on the DBM
modules available on the user's
13 matches
Mail list logo
