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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
Subject: bug#18522: 24.4.50; mapcar is very slow
Date: Wed, 24 Feb 2016 19:42:41 +0200

> Date: Wed, 24 Feb 2016 11:15:28 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> 
>  > 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.
> 
> Doesn't that remove unmarked buffers only?

Of course.  But why would killed buffers be marked?

>  >> 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.
> 
> One potential hole are window configurations.  Each window maintains two
> lists for navigating the buffers previously shown in that window.  For
> live windows, these lists are hopefully updated when killing a buffer.
> But if you store such a window in a window configuration and forget
> about that configuration, the buffers from those lists are not reclaimed
> IIUC.

What do you mean by "forget"?  Forgetting a Lisp object means it is
not referenced by any other object, so it will be GCed, together with
the buffers it references.  Right?

> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.

What would you use instead?

Previous Next

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