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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Münster <pmlists <at> free.fr>
Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
Subject: Re: bug#18522: 24.4.50; mapcar is very slow
Date: Tue, 23 Feb 2016 18:23:56 +0200

> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at,  larsi <at> gnus.org,  18522 <at> debbugs.gnu.org
> Date: Tue, 23 Feb 2016 12:19:30 +0100
> 
> On Mon, Feb 22 2016, Eli Zaretskii wrote:
> 
> > So now the question becomes: which part of Fset_default?  I thought it
> > was the loop over all the buffers, but your session seems to say it
> > couldn't be.
> 
> Why?

Because your session has very few buffers, and yet you see a much more
massive slowdown.

> This is what I read in buffer.h:
> 
> --8<---------------cut here---------------start------------->8---
> /* Chain of all buffers, including killed ones.  */
> 
> extern struct buffer *all_buffers;
> 
> /* Used to iterate over the chain above.  */
> 
> #define FOR_EACH_BUFFER(b) \
>   for ((b) = all_buffers; (b); (b) = (b)->next)
> --8<---------------cut here---------------end--------------->8---
> 
> "including killed ones" !

You interpret that comment too literally: it means killed buffers that
were not yet GC'ed.  You will see in alloc.c that sweep_buffers
removes killed buffers from all_buffers and recycles their memory.

> That means, the chain gets bigger and bigger, whenever I read an article
> or I reply or I send a new message or whatever.

If Emacs did that, it would have been a very serious bug and a huge
memory sink.

Previous Next

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