Bug #102188 for Date-Manip: Surprising ParseDate() performance differential, DM5 vs. DM6

Your timing, though accurate, does not reflect anything useful. Let me explain. Date::Manip 5.x made extensive use of caching... i.e. if you called a subroutine with the same arguments, rather than redoing the calculation, it made use of the cached value determined previously. Date::Manip 6.x also caches values, but it is a far more complex and powerful module, and it does more extra work than 5.x, so there is more overhead for each date operation. However, the actual work is far more optimized, so even with the overhead (much of which is actually designed to make the operation faster), overall it is faster. Your simple script does not parse a single date 3000 times... instead, it parses a single date and then uses cached values the other 2999 times. Since 5.x doesn't have as much overhead, you're really not exercising any of the date operations, so the factor of 3 is not surprising... but also not representative of anything useful. If you change your script to be a more real world script, you'll find the results shift in favor of 6.x. For example, change the middle portion of your script to read: ####################################### my $t0 = [gettimeofday()]; foreach my $d (1..12) { foreach my $h (10..22) { foreach my $m (10..30) { foreach my $s (10..15) { my $date_in = 'Fri, $d Jan 2015 $h:$m:$s -0500'; my $date_out = ParseDate($date_in); }}}} my $t1 = [gettimeofday()]; my $et = tv_interval($t0, $t1); ####################################### Now, your script is actually parsing unique dates (19,656 of them to be exact). They are all within a few days of each other, and this is a very real-world situation (you might get it parsing a log file for example). Now, 6.x is faster (though not by a lot) than 5.x. If you switch to the OO method (which is actually how 6.x is best used), then you get a slight speedup (by discarding the overhead of calling the functional interface which immediately calls the OO methods. That script now looks like: ####################################### use Date::Manip::Date; my $obj = new Date::Manip::Date; printf(STDERR "\n"); #printf(STDERR "D::M Version: %s\n", DateManipVersion(1)); my $t0 = [gettimeofday()]; foreach my $d (1..12) { foreach my $h (10..22) { foreach my $m (10..30) { foreach my $s (10..15) { my $date_in = 'Fri, $d Jan 2015 $h:$m:$s -0500'; #my $date_out = ParseDate($date_in); $obj->parse($date_in); }}}} ####################################### Finally, with the OO method, you can optimize it by discarding some parts of the parsing. So, if you change the parse line to: $obj->parse($date_in,"noiso8601"); you get additional speedup since ISO 8601 dates are the first ones parsed, and your format falls into the second category of dates parsed. With these changes, the ratio of run times is: 5.x 1.000 6.x 0.937 6.x OO 0.935 + opt 0.894 At some point, I do intent to add a lot more timing information... it interests me, and will be useful, but I haven't taken the time to do all the work to do it yet. However, Date::Manip 6 will outperform 5 in practically every way.

One other thing that I wanted to note, but omitted in my previous reply: If you look in the initial test script that I included, the dates DO have an offset, but they are all the same offset. In real life, this is the more common problem since most of the dates that you read will come from a single timezone. Your newest example (which is still real life, but a little less common) has them coming from many different timezones. This does slow down Date::Manip since it has to calculate and cache descriptions of so many different timezones, so it's making a lot less use of some of the internal speedups (i.e. internally cached values). So, when the dates all come from a single timezone, 6.x outperforms 5.x. When they come from many different timezones, 5.x outperforms 6.x... but it gets the values wrong.