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 command
I have a question on DateTime performance
I really want to use DateTime in most of my projects, especially when
I'm working with the likes of Class::DBI, to give the proper abstraction
for handling TIMESTAMP/DATETIME fields, as well as the free validation I
get from DateTime
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 fa
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 Dat
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 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
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 calculat
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 b
On Mon, Aug 04, 2003 at 10:10:54AM -0400, John Siracusa wrote:
>
> Does it need to do that? I mean, sure, eventually it might have to do that
> if I want to do some sort of date manipulation, or even just fetch or print
> the date. But does it have to really do anything at all during object
> co
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 ev
> > 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 wo
On Tuesday, August 5, 2003, at 01:26 PM, Eugene van der Pijll wrote:
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. [...]
Probably this changes the behaviour if t
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" argumen
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::
On 1/22/05 8:38 PM, Daisuke Maki wrote:
> I really really want to make it faster. I know that it's impossible to
> match sprintf + localtime, but wouldn't it be nice if the difference was
> an order of magnitude lower... ;)
>
> So ... are we going to address this?
I spent a little time seeing how
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 or
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 h
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/
> site_p
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;
[EMA
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 eit
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
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 ->ut
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
> 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 th
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 wrote:
> In the spirit of TIMTOWTDI, there's my DateTime::LazyInit module which I
> wrote for
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
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 b
++ 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 the
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.
>
31 matches
Mail list logo
