in reply to Date comparisons

Though Date::Manip is a really powerful tool, as his author states in the documentation, it's nearly always an overkill to use it in simple tasks.

You should probably want to benchmark Date::Manip with other modules like Date::Calc with the Delta_days() function, which might be what you're looking for.

Update:

I just benchmarked both module and Manip is really slower than Calc (but remember that Calc is not 100% Perl, and Date::Manip parses each time the dates we provide)

Here's the code and the results of the Benchmark, if anyone wants to optimize, criticize, or bencmark with other module:

$d1 = '14', $m1 = '08', $y1 = '2001'; $d2 = '16', $m2 = '12', $y2 = '2001'; $dt1 = "2001/08/14"; $dt2 = "2001/12/16"; timethese(-10, { # running for at least 10 seconds 'Calc' => \&Calc, 'Manip' => \&Manip, }); sub Calc { my $Dd = Date::Calc::Delta_Days($y1,$m1,$d1,$y2,$m2,$d2); } sub Manip { my $date1=Date::Manip::ParseDate($dt1); my $date2=Date::Manip::ParseDate($dt2); my $flag=Date::Manip::Date_Cmp($date1,$date2); }

The results:

Benchmark: running Calc, Manip, each for at least 10 CPU seconds... Calc: 12 wallclock secs (11.04 usr + 0.00 sys = 11.04 CPU) @ 142935.85/s (n=1577440) Manip:10 wallclock secs (10.56 usr + 0.00 sys = 10.56 CPU) @ 104.88/s (n=1107)

Is this making Date::Calc 1300 times faster than Date::Manip?

-- Briac

<kbd>--
PerlMonger::Paris(http => 'paris.pm.org');</kbd>

Replies are listed 'Best First'.
(tye)Re: Date comparisons + Benchmark
by tye (Sage) on Feb 09, 2001 at 19:27 UTC

    Yes, the numbers say that your calculations with Date::Calc run 1300 times faster than your calculations with Date::Manip. You weren't "comparing apples to apples" (the Date::Calc loop doesn't do any "parsing" at all), however, so that speed difference is going to be, at least a bit, overstated.

    But much more important than that, is that the numbers say that reparsing two dates and then comparing them can be done in 1/100th of a second with Date::Manip (on your computer with those simple date formats). Because even being 1300-times faster doesn't mean that you'll even notice the difference. (:

    So, for example, if we wanted to compute a date difference for each news article as we display it, well, 1/100th of a second vs. 1e-5 seconds isn't going to make a noticeable difference at all. If we want to compute a date difference for thousands of news articles in order to select a dozen articles to list, then this will probably make a quite noticeable difference.

    But your benchmarks don't apply at all well to the original problem. If the news articles came with month, day, and year already parse out as numbers, then I probably would just use Time::Local since it just exposes an ANSI-standard-C function.

    Given the task of parsing dates in news articles, I'd start with Date::Manip, since that is exactly the kind of problem it was designed for (since Usenet news articles usually have dates encoded in different formats and from different timezones and Date::Manip knows how to take that into account) and using it would require very little coding on my part. If the results seemed slow to me, then I'd look at how much work it would take to use something else and then decide whether it was worth my time to produce enough working code that I could compare the subjective speed difference for my specific task.

            - tye (but my friends call me "Tye")

      A lot of the inefficiency in Date::Manip (in re-parsing) could be eliminated by caching the results in seconds; e.g. using  Date_SecsSince1970GMT to create a hash mapping message ID's to dates in seconds. This lets Date::Manip do the "magic" of normalizing various date formats and TZ's into an "universal" format, but the actual sort & search would now be against a list of (large) integers.