GNU bug report logs - #18522
occasional slow performance in some Gnus code

Previous Next

Packages: gnus, emacs;

Reported by: Peter Münster <pmlists <at> free.fr>

Date: Mon, 22 Sep 2014 10:38:02 UTC

Severity: normal

Tags: fixed

Found in version 24.4.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: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
Subject: bug#18522: 24.4.50; mapcar is very slow
Date: Fri, 26 Feb 2016 10:48:16 +0200
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Peter Münster <pmlists <at> free.fr>,
>   18522 <at> debbugs.gnu.org
> Date: Fri, 26 Feb 2016 13:43:44 +1030
> 
> >  . parse-time-string should try to avoid binding case-fold-search
> >    globally, or at all
> 
> It's kinda weird.  This starts with:
> 
> (defun parse-time-string (string)
> 
> [...]
> 
> 	(temp (parse-time-tokenize (downcase string))))
> 
> which calls
> 
> (defsubst parse-time-string-chars (char)
>   (save-match-data
>     (let (case-fold-search str)
>       (cond ((eq char ?+) 1)
> 	    ((eq char ?-) -1)
> 	    ((eq char ?:) ?d)
> 	    ((string-match "[[:upper:]]" (setq str (string char))) ?A)
> 	    ((string-match "[[:lower:]]" str) ?a)
> 	    ((string-match "[[:digit:]]" str) ?0)))))
> 
> !?
> 
> Since we've already downcased the entire string, both the
> `case-fold-search' and the match to [[:upper:]] seem rather
> nonsensical?

Yes, weird.  And even if someone thought of using
parse-time-string-chars in other places that don't necessarily
downcase the string, I don't understand why we should test a character
by making it a string, then matching against [:upper:].  Maybe I'm
missing something.




This bug report was last modified 8 years and 170 days ago.

Previous Next


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