On Wed, 20 Jul 2005, Daisuke Maki wrote:
On a related note, seems like Dave's change to Build.PL only works with the
latest (dev?) Module::Build (some missing methods are reported as errors in
my environment). If you do not have the correct version of Module::Build, you
may need to revert that
I committed the next batch of XS port for DT::TimeZone. This time
_span_for_datetime and all of its corresponding subroutines
(offset_for_datetime() et al) have been ported to XS, as well as fixes
to some buglets that I introduced in my last batch of commits.
On a related note, seems like Da
All,
I have just committed another iteration of DateTime::TimeZone XS port
into CVS. I've yet to be able to correct the memory footprint problem,
but I've made the following changes:
- Change XS based objects from hash-based to scalar based and
save tons of memory.
- Optimize XS code
something else entirely is actually using the extra memory...
Rob
- Original Message -
From: "Daisuke Maki" <[EMAIL PROTECTED]>
To: "Dave Rolsky" <[EMAIL PROTECTED]>
Cc: "datetime"
Sent: Wednesday, July 13, 2005 1:59 AM
Subject: Re: DateTime::Tim
FWIW
I've come down to around 900 bytes per structure (max), and yet still 10MB
more memory is consumed at this point. Hmmm.
--d
Quoting Dave Rolsky <[EMAIL PROTECTED]>:
> If this could be integrated with using C data structures that'd be pretty
> cool. I have the code somewhere if you can't find it.
I'll take a look when I find some time. I've been looking for an excuse to mess
with XS anyway.
As I recall, most of the wo
> You can't look at this to determine how big it really is. I'm pretty sure
> Devel::Size doesn't look at the C data structure. You should use the
> script I sent in an earlier email along with top or something like that.
>
> You may have already fixed it ;)
eh, no. I've been looking at top wit
On Mon, 11 Jul 2005, Matt Sisk wrote:
At some point a while back, I analyzed the data structures used in forming the
timezone objects and found that there was a lot of redundant structures,
particularly in cases where you were loading a large number of zones. I hacked
the data structure to re-us
On Mon, 11 Jul 2005, Daisuke Maki wrote:
So I spent the last four days trying to fix whatever it was that causing
this seeming increase in memory size, and I'm still at quite a loss.
I've optimize the memory usage in the code as much as I could, and I'm
pretty much out of ideas, so I've posted a
At some point a while back, I analyzed the data structures used in forming the
timezone objects and found that there was a lot of redundant structures,
particularly in cases where you were loading a large number of zones. I hacked
the data structure to re-use common references whenever possible and
So I spent the last four days trying to fix whatever it was that causing
this seeming increase in memory size, and I'm still at quite a loss.
I've optimize the memory usage in the code as much as I could, and I'm
pretty much out of ideas, so I've posted a question at perlmonks:
(http://www.perlmonk
Daisuke Maki wrote:
I'm thinking the memory inefficiency + the way util.o is one of the
culprits. let me try a few tests...
Just FYI, it has recently come to my attention that code like yours (and my
version.pm code) won't compile properly under GCC 4.0. Specifically, your
util.h headers may
> But I'm still rather mystified. How can the C structs possibly be
> bigger than Perl's data structures?
I'm thinking the memory inefficiency + the way util.o is one of the
culprits. let me try a few tests...
--d
On Fri, 8 Jul 2005, Daisuke Maki wrote:
I'm happy to announce that I just commited the first cut of the new XS
implementation of DateTime::TimeZone to CVS.
For now the only thing I ported are a few methods and the $spans structure,
which used to be a AoA. This is now a list of C structs, and a
All,
I'm happy to announce that I just commited the first cut of the new XS
implementation of DateTime::TimeZone to CVS.
For now the only thing I ported are a few methods and the $spans structure,
which used to be a AoA. This is now a list of C structs, and are loaded on
demand.
Some internal
15 matches
Mail list logo
