GNU bug report logs - #14776
24.3.50; [PATCH] parse-time-string performance

Previous Next

Package: emacs;

Reported by: Andreas Politz <politza <at> hochschule-trier.de>

Date: Wed, 3 Jul 2013 01:23:01 UTC

Severity: wishlist

Tags: patch, wontfix

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #32 received at 14776 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Politz <politza <at> hochschule-trier.de>
Cc: 14776 <at> debbugs.gnu.org
Subject: Re: bug#14776: 24.3.50; [PATCH] parse-time-string performance
Date: Thu, 04 Jul 2013 23:15:11 +0200
Andreas Politz <politza <at> hochschule-trier.de> writes:

>> (benchmark-elapse (dotimes (i 10000) (parse-time-string "Thu, 04 Jul
>> 2013 20:06:00 +0200")))
>> => 1.120856647
>
> => 0.215108395
> ;-O

Wow, that's a pretty impressive speed-up.  I do see one issue, though --
it doesn't parse 2-digit years?  That's a requirement.

Anyway, with this large speed-up, I think we should definitely consider
swapping out the current parse-time code with your code.  Could you
collect a bunch of Date headers from the wild and see whether the old
and new versions agree on them all?

> It looks that way, i.e. parse-time-string is pretty simple compared to
> that.  But most Date header I've seen popping up in my mail seem to
> adhere to a strict rfc2822 format anyway, except for the occasional
> non-strict timezone.

Yes, mailers have gotten a lot better about adhering to the RFC2822 date
format the last decade.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/




This bug report was last modified 5 years and 335 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.