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

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Peter Münster <pmlists <at> free.fr>
Cc: 18522 <at> debbugs.gnu.org
Subject: Re: bug#18522: 24.4.50; mapcar is very slow
Date: Sun, 07 Feb 2016 17:31:00 +1100

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

> On Sat, Feb 14 2015, Lars Ingebrigtsen wrote:
>
>> After you enter the debugger, can you go to the *scratch* buffer and
>>
>> `M-: (pp threads (current-buffer)) RET'
>
> Hi,
>
> `threads' is not defined then... Instead I've modified
> `gnus-sort-threads' to print `threads' into the buffer.
>
> In both cases it's the same. Please find attached an example.

Hm.  That looks totally normal, I think.

So our supposition here is: The time is spent in parse-time-string.  The
data it's running on is the same.  But after Emacs has run a significant
amount of time, parse-time-string becomes slower.

To test that, does 

(benchmark-run 1
 (dotimes (i 10000)
  (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))

run faster in a newly started Emacs than in one that has been running
for a long time?

An alternative explanation might be that you're inadvertently loading an
alternative version of parse-time.el somewhere, and getting an
uncompiled version of the function.  What does `C-h f parse-time-string'
say in a slow and a fast Emacs?

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