On Saturday 05 May 2012 17:14:52 N Heinrichs wrote:
++ to using precomposed TZ object (as you observed, supplying only the
name as a string still results in lengthy DT:TZ object creation
overhead.)
If you use them, I would also precompose any necessary Formatter or
Locale objects.
Thanks
++ to using precomposed TZ object (as you observed, supplying only the
name as a string still results in lengthy DT:TZ object creation
overhead.)
If you use them, I would also precompose any necessary Formatter or
Locale objects.
Depending on how you're parsing the date strings and composing
On Thursday 03 May 2012 02:10:04 you wrote:
On 2012.5.1 3:29 PM, Philipp K. Janert wrote:
However, when working through a files with a few
tens of millions of records, DateTime turns into a
REAL drag on performance.
Is this expected behavior? And are there access
patterns that I can
On Thursday 03 May 2012 02:14:45 you wrote:
From: Philipp K. Janert [mailto:jan...@ieee.org]
Sent: Wednesday, 2 May 2012 8:29 AM
Question:
When using DateTime for a large number of
instances, it becomes a serious performance
drag.
...
Is this expected behavior? And are
Question:
When using DateTime for a large number of
instances, it becomes a serious performance
drag.
A typical application for me involves things like
log files: I use DateTime to translate the timestamps
in these files into a canonical format, and then get
information such as day-of-week
On 2012.5.1 3:29 PM, Philipp K. Janert wrote:
However, when working through a files with a few
tens of millions of records, DateTime turns into a
REAL drag on performance.
Is this expected behavior? And are there access
patterns that I can use to mitigate this effect?
(I tried to supply
From: Philipp K. Janert [mailto:jan...@ieee.org]
Sent: Wednesday, 2 May 2012 8:29 AM
Question:
When using DateTime for a large number of
instances, it becomes a serious performance
drag.
...
Is this expected behavior? And are there access
patterns that I can use to mitigate this
In the spirit of TIMTOWTDI, there's my DateTime::LazyInit module which I wrote
for this sort of case. It only inflates to a full DateTime object when you call
methods that aren't simple.
http://search.cpan.org/~rickm/DateTime-LazyInit-1.0200/lib/DateTime/LazyInit.pm
Caveat: I haven't tested
I love and use DateTime for for 10s of millions of records at once I
would be choosing Date::Calc instead and dealing with any necessary
futzy bits manually.
On Thu, May 3, 2012 at 2:53 AM, Rick Measham r...@measham.id.au wrote:
In the spirit of TIMTOWTDI, there's my DateTime::LazyInit module
arie.ha...@gmail.com wrote:
Our project requres getting time-zone offset for the given time-zone
id at the current time.
You can speed things up a bit by using the timezone modules in isolation.
You can construct a fake DateTime class, which only provides the methods
-utc_rd_as_seconds and
Hey!
Why DateTime module is loaded so slow?
This simple script that just imports DateTime is executed for 1 second
approximately:
use DateTime;
Can I make it faster?
Our project requres getting time-zone offset for the given time-zone
id at the current time.
This is the primary reason I use
On Fri, 23 Jan 2009, arie.ha...@gmail.com wrote:
Why DateTime module is loaded so slow?
This simple script that just imports DateTime is executed for 1 second
approximately:
use DateTime;
Can I make it faster?
Yes, you need a faster computer!
auta...@houseabsolute:~/projects/R2$ time perl
On Mon, Jan 16, 2006 at 06:21:54PM -0800, [EMAIL PROTECTED] wrote:
One might hope that a script like this:
test3
#!/usr/bin/perl
BEGIN {
no lib qw|/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/
lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/
On Wed, Jan 18, 2006 at 08:38:13AM -0800, [EMAIL PROTECTED] wrote:
Then no lib isn't doing what you want.
Agree. But, that is the point. Outside of recompiling perl with new
paths or significantly altering DateTime to use far fewer
dependancies nothing can really be done.
test4
Then no lib isn't doing what you want.
Agree. But, that is the point. Outside of recompiling perl with new
paths or significantly altering DateTime to use far fewer
dependancies nothing can really be done.
test4
#!/usr/bin/perl
BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC }
use DateTime;
Do your traces show it still searching all the removed paths?
yes
There's no way the above should be doing that, unless you're
loading DateTime earlier, via sitecustomize.pl or $PERL5OPT?
Neither of the items you have identified are used in any way during
these tests. I would expect if
I don't consider this to be completely a DateTime issue however I
thought I would share my findings to this list for consideration.
I'm using the latest release of DateTime with perl 5.8 (Standard RPM
distro) for FC4 on a very old 166MHz Pentium system. So I don't
expect this system to
Unfortunately, it's a known problem that CentOS suffers from too (@[EMAIL
PROTECTED]).
This also makes reading error output incredibly difficult since a full screen
is given to list @INC. Instead of a few folks who are upgrading systems
having to set PERL5LIB everyone else has to recompile perl
Jerrad Pierce wrote:
Unfortunately, it's a known problem that CentOS suffers from too (@[EMAIL
PROTECTED]).
This also makes reading error output incredibly difficult since a full screen
is given to list @INC. Instead of a few folks who are upgrading systems
having to set PERL5LIB everyone else
John Siracusa schreef:
Okay, here's a simple implementation of a memoized
DateTime::Locale::load().
A solution that is more or less equivalent, is to change the
DefaultLocale routine. At the moment, $DefaultLocale is saved as a
string; every time DT::new() is called without a locale argument,
A solution that is more or less equivalent, is to change the
DefaultLocale routine. [...]
Probably this changes the behaviour if the default locale is aliased.
But IMHO, that's probably for the better.
Yeah, that was my concern: add_aliases() and friends in
DateTime::Locale would have
On Mon, Aug 04, 2003 at 11:32:15PM -0500, Dave Rolsky wrote:
Maybe that looks more sane to you?
What makes no sense is for BEGIN to show up as a significant chunk of the
time it would take to do anything, since this stuff should only happen
once. I'm somewhat skeptical that Devel::DProf
On 8/4/03 12:26 AM, Dave Rolsky wrote:
# ... includes args: year, month, day, hour, minute, second
DateTime-new(...): 16 wallclock secs @ 687.29/s
(14.48 usr + 0.07 sys = 14.55 CPU)
This does a lot of work, including calculating both UTC local times,
which involves calculating leap
On 8/4/03 10:10 AM, John Siracusa wrote:
On 8/4/03 12:26 AM, Dave Rolsky wrote:
# ... includes args: year, month, day, hour, minute, second
DateTime-new(...): 16 wallclock secs @ 687.29/s
(14.48 usr + 0.07 sys = 14.55 CPU)
This does a lot of work, including calculating both UTC local
On 8/4/03 1:25 PM, Ben Bennett wrote:
Why not make your module be lazy about whether or not it creates a
DateTime?
I thought of that, but I also use the act of creating a DateTime object to
check the validity of date attributes. Anyway, I think there's room for
DateTime-new() optimization even
I was profiling a database-backed mod_perl application recently. A
particular request was taking several seconds to complete. At first I
thought the database was the bottleneck, but the request included only
one database query, and that query completed in about 300msec when run
from a
On Sun, 3 Aug 2003, John Siracusa wrote:
CGI-new(''): 5 wallclock secs @ 1869.16/s
(5.25 usr + 0.10 sys = 5.35 CPU)
CGI's constructor really doesn't do much at all, especially if there's no
query string or form submission to handle.
Date::Simple-new('2003-01-01'): 2 wallclock secs @
27 matches
Mail list logo
