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, 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
>
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 be
Matt Sisk wrote:
If you wanted to avoid the up-front cost, as well as the cost of unique
key generation at compile/runtime, another option would be to have the
program that generates the modules from Olson data pre-generate unique
keys for each span. Then have a 'status' hash in each TZ-specific
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 som
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
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";
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
S
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 (a
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 zon
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
> 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 to try and determine the level of interest in
Dave Rolsky wrote:
after some thinking about how to compare the "inconvertible" units, I
came up with an ugly hack that will work for "most" cases - the border
cases where it fails, are not yet detected, but I'm working on that. The
patch passes all my ad-hoc tests, I'll run it later against the D
(I am too stupid - I forgot to CC the list)
Original Message
Subject: Re: [Fwd: DateTime::Duration comparisions]
Date: Thu, 13 Nov 2003 10:16:25 +0100
From: Max Maischein <[EMAIL PROTECTED]>
To: Dave Rolsky <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
14 matches
Mail list logo
