hi dave and all :)
so, we're starting to implement new date/time handling here at the office.
the DateTime suite seemed the natural way to go for obvious reasons (it
didn't exist or was relatively new the last few cycles, should you ask).
however, in implementing it we found something that might
On 2/28/05 9:42 AM, Geoffrey Young wrote:
DateTime objects are _huge_ for non-UTC timezones. consider:
[...]
print Dumper $dt;
I always just assumed that those giant structures exist once in memory and
are simply referenced by each DT object. I never bothered to actually
check, but c'mon,
On Mon, 28 Feb 2005, Geoffrey Young wrote:
now, because we have a ton of different things that need to be individually
wrapped in objects, this means a megaton of data will be floating around our
model objects, and even more floating around in our object caches.
so, the question I have is whether
On Mon, 28 Feb 2005, Geoffrey Young wrote:
The hugeness is the DateTime::TimeZone object, not DateTime itself.
Those are all singletons, so you only pay the price once per time zone.
ok, but how does that affect storable-style serializations? I noticed that
you have some storable hooks, but I
On 2/28/05 1:26 PM, Dave Rolsky wrote:
On Mon, 28 Feb 2005, Geoffrey Young wrote:
The hugeness is the DateTime::TimeZone object, not DateTime itself.
Those are all singletons, so you only pay the price once per time zone.
ok, but how does that affect storable-style serializations? I noticed
On Mon, 28 Feb 2005, John Siracusa wrote:
Can't you just nuke the giant DT:TZ ref before
freezing and have it
auto-re-vivify when first used after it's thawed?
IOW, save the TZ string
(floating, local, America/Chicago) and then
re-grab a ref to the
DT::TZ singleton as needed. That
Oh yeah. That's what it already does ;)
It should do that, but there seems to be something wrong:
with recent versions (the ones that existed before this weekend's release) I
get very similar sizes using nstore:
-rw-rw-r--1 geoffgeoff 180 Feb 28 14:02 stored-nonutc
On Mon, 28 Feb 2005, Geoffrey Young wrote:
It should do that, but there seems to be something wrong:
with recent versions (the ones that existed before this weekend's release) I
get very similar sizes using nstore:
-rw-rw-r--1 geoffgeoff 180 Feb 28 14:02 stored-nonutc
-rw-rw-r--
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote:
On Mon, 28 Feb 2005, John Siracusa wrote:
Can't you just nuke the giant DT:TZ ref before
freezing and have it
auto-re-vivify when first used after it's thawed?
IOW, save the TZ string
(floating, local, America/Chicago) and then
re-grab a ref to the
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote:
On Mon, 28 Feb 2005, John Siracusa wrote:
Can't you just nuke the giant DT:TZ ref before
freezing and have it
auto-re-vivify when first used after it's thawed?
IOW, save the TZ string
(floating, local, America/Chicago) and then
On Mon, 28 Feb 2005 [EMAIL PROTECTED] wrote:
Note that this was added in DT::TZ 0.26. DT.pm
itself didn't have to be
changed, IIRC.
I'm sorry - I just installed a new DT::TZ from CPAN and I'm still
getting stringified references instead of names.
That's cause STORABLE_freeze returns some data
11 matches
Mail list logo
