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


View this message in rfc822 format

From: Andreas Politz <politza <at> hochschule-trier.de>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 14776 <at> debbugs.gnu.org
Subject: bug#14776: 24.3.50; [PATCH] parse-time-string performance
Date: Thu, 04 Jul 2013 23:08:33 +0200
[Message part 1 (text/plain, inline)]
Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> It's not much of a bottleneck, no:
>
> (benchmark-elapse (dotimes (i 10000) (parse-time-string "Thu, 04 Jul 2013 20:06:00 +0200")))
> => 1.120856647

=> 0.215108395
;-O

But only with this:
[parse-time-rfc2822.el (application/emacs-lisp, inline)]
[Message part 3 (text/plain, inline)]
> But sorting a summary buffer of 5K messages on Date (which some people
> do) might get a performance boost.  But I was thinking that it might be
> more likely that parse-datetime parses more date strings correctly than
> the version in parse-time.el.  

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.

-ap

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.