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


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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
Subject: Re: bug#18522: 24.4.50; mapcar is very slow
Date: Wed, 24 Feb 2016 19:16:27 +0100
> Of course.  But why would killed buffers be marked?

Because they are still referenced from somewhere else.

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

Each window in a window configuration stores all the buffers it has ever
shown.  Now window configurations are sometimes stored in registers.  I
could imagine users that store a couple of configurations in registers
and "forget" about them in the sense that they do not restore from some
of those stored configurations for quite some time or the rest of the
session.

>> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.
>
> What would you use instead?

A macro that excludes killed buffers.  What's the purpose of

		  if (!PER_BUFFER_VALUE_P (b, idx))
		    set_per_buffer_value (b, offset, value);

in a killed buffer?

martin




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.