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

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
Subject: bug#18522: 24.4.50; mapcar is very slow
Date: Sun, 28 Feb 2016 14:32:46 +1030

Eli Zaretskii <eliz <at> gnu.org> writes:

>> (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)))))

[...]

> 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.

No, that's also rather puzzling.  Looking at the rest of the code, we
don't really handle anything other than [a-z] and [0-9] here, so using a
regexp instead of a (<= ?0 char ?9) (etc.) also seems odd.  And losing
those `string-match' calls would also mean we could get rid of the
`save-match-data' call.

I think I'll put together a test harness for `parse-time' and then clean
up this function further.

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

Previous Next

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