From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "Peter Münster" <pmlists@free.fr>, 18522@debbugs.gnu.org
Subject: bug#18522: 24.4.50; mapcar is very slow
Date: Fri, 26 Feb 2016 13:43:44 +1030 [thread overview]
Message-ID: <87egc0noyf.fsf@gnus.org> (raw)
In-Reply-To: <83vb5cg4r6.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Feb 2016 17:59:41 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
> . most of the buffers over which set-default loops were actually
> killed, but they are still in all_buffers list which set-default
> traverses, although they were supposed to be removed by GC
> . killed buffers are not removed from all_buffers by GC because
> they are referenced by gnus-buffers
> . gnus-buffers references killed buffers because Peter kills buffers
> behind Gnus back, instead of letting them be killed through
> gnus-kill-buffer, which would have removed them from gnus-buffers
It's probably not just Peter, but... code somewhere. My gnus-buffers
is currently:
(#<buffer *unsent wide reply to Eli Zaretskii*> #<buffer *Article nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *Original Article nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *Summary nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *sent wide reply to Eli Zaretskii*> #<buffer *sent wide reply to Richard Stallman*> #<killed buffer> #<buffer *sent wide reply to Thierry Volpiatto*> #<buffer *sent wide reply to Lars Magne Ingebrigtsen*> #<buffer *sent wide reply to Matthew Styskal*> #<buffer *sent wide reply to Paul Eggert*<3>> #<buffer *sent wide reply to Zachary Kanfer*> #<buffer *sent wide reply to David Engster*> #<buffer *sent wide reply to Paul Eggert*<2>> #<buffer *sent wide reply to Paul Eggert*> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<buffer *gnus article copy*> #<killed buffer> #<buffer *nnmail message-id cache*> #<buffer *nnimap hermes.netfonds.no nil *nntpd**> #<buffer *gnus work*> #<buffer .newsrc-dribble> #<buffer *Gnus agent overview*> #<buffer *Group*>)
I'll fix the gnus-{add,kill}-buffer functions so that they remove all
the killed buffers. That should help keep that list down to a
reasonable length, and let all the killed buffers be GC'd.
> If the above is an accurate account of what we've discovered, then we
> have several factors here that conspire to make Peter's Gnus slow:
>
> . parse-time-string should try to avoid binding case-fold-search
> globally, or at all
It's kinda weird. This starts with:
(defun parse-time-string (string)
[...]
(temp (parse-time-tokenize (downcase string))))
which calls
(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)))))
!?
Since we've already downcased the entire string, both the
`case-fold-search' and the match to [[:upper:]] seem rather
nonsensical? So that should be fixed, but:
> . set-default should skip killed buffers
Yes. I think that would be a win in general.
> For the second issue, I propose to modify set-default to use
> FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER. Does anyone see a
> problem with that?
Hm... If a buffer is killed, do the local variables still have an
effect? I'm thinking of code like:
(with-temp-buffer
(setq-local foo 'bar)
(kill-buffer (current-buffer))
(let ((buf (current-buffer)))
(with-temp-buffer
(let ((foo 'zot))
(set-buffer buf)
foo))))
Well, that answered itself. :-) It returns zot. (If we don't kill it
returns bar.) So I don't see any reason not to use FOR_EACH_LIVE_BUFFER
here.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2016-02-26 3:13 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-22 10:37 bug#18522: 24.4.50; mapcar is very slow Peter Münster
2014-09-22 10:43 ` bug#18522: further information Peter Münster
2014-09-22 12:49 ` bug#18522: 24.4.50; mapcar is very slow Stefan Monnier
2014-09-22 13:47 ` Peter Münster
2014-09-25 21:36 ` Peter Münster
2014-09-26 6:57 ` Eli Zaretskii
2014-09-26 7:15 ` Peter Münster
2014-09-26 7:36 ` Eli Zaretskii
2014-10-01 19:55 ` Peter Münster
2014-10-01 19:58 ` Glenn Morris
2014-10-01 20:25 ` Peter Münster
2015-02-13 8:26 ` Lars Ingebrigtsen
2015-02-13 14:39 ` Peter Münster
2015-02-14 4:19 ` Lars Ingebrigtsen
2015-03-02 14:34 ` Peter Münster
2015-07-20 12:52 ` Peter Münster
2016-02-07 6:31 ` Lars Ingebrigtsen
2016-02-17 16:00 ` Peter Münster
2016-02-19 5:15 ` Lars Ingebrigtsen
2016-02-19 8:27 ` Peder O. Klingenberg
2016-02-19 8:38 ` Eli Zaretskii
2016-02-19 10:06 ` Nicolas Richard
2016-02-19 10:12 ` Peder O. Klingenberg
2016-02-19 22:46 ` Lars Ingebrigtsen
2016-02-20 8:14 ` Eli Zaretskii
2016-02-20 8:33 ` Peter Münster
2016-02-20 9:51 ` Eli Zaretskii
2016-02-21 11:00 ` Peter Münster
2016-02-21 11:08 ` Andreas Schwab
2016-02-21 11:09 ` martin rudalics
2016-02-21 11:30 ` Peter Münster
2016-02-21 13:41 ` Michael Heerdegen
2016-02-21 14:02 ` Peter Münster
2016-02-21 14:36 ` Peter Münster
2016-02-21 14:54 ` Peter Münster
2016-02-21 16:14 ` Eli Zaretskii
2016-02-21 18:03 ` Peter Münster
2016-02-21 20:45 ` Eli Zaretskii
2016-02-22 7:37 ` Peter Münster
2016-02-22 16:22 ` Eli Zaretskii
2016-02-22 20:41 ` Peter Münster
2016-02-22 20:56 ` Eli Zaretskii
2016-02-23 11:19 ` Peter Münster
2016-02-23 16:23 ` Eli Zaretskii
2016-02-23 16:35 ` Peter Münster
2016-02-23 16:48 ` Andreas Schwab
2016-02-24 10:22 ` Peter Münster
2016-02-23 17:47 ` Eli Zaretskii
2016-02-24 10:25 ` Peter Münster
2016-02-24 17:39 ` Eli Zaretskii
2016-02-24 18:00 ` Peter Münster
2016-02-24 18:23 ` Eli Zaretskii
2016-02-24 20:03 ` Peter Münster
2016-02-24 20:26 ` Eli Zaretskii
2016-02-25 8:06 ` Peter Münster
2016-02-24 23:53 ` Lars Ingebrigtsen
2016-02-25 8:08 ` Peter Münster
2016-02-25 15:59 ` Eli Zaretskii
2016-02-25 18:10 ` Peter Münster
2016-02-25 18:25 ` Eli Zaretskii
2016-02-26 11:05 ` Peter Münster
2016-02-26 11:13 ` Eli Zaretskii
2016-02-26 11:35 ` Peter Münster
2016-02-28 4:10 ` Lars Ingebrigtsen
2016-02-28 8:07 ` Peter Münster
2016-02-28 15:48 ` Eli Zaretskii
2016-02-29 2:21 ` Lars Ingebrigtsen
2016-02-29 10:33 ` bug#18522: killed buffers not GCed (was: bug#18522: 24.4.50; mapcar is very slow) Peter Münster
2016-02-28 5:12 ` bug#18522: 24.4.50; mapcar is very slow Lars Ingebrigtsen
2016-02-26 3:18 ` Lars Ingebrigtsen
2016-02-26 3:13 ` Lars Ingebrigtsen [this message]
2016-02-26 8:48 ` Eli Zaretskii
2016-02-28 4:02 ` Lars Ingebrigtsen
2016-02-26 9:28 ` Eli Zaretskii
2016-02-28 4:04 ` Lars Ingebrigtsen
2017-01-25 20:09 ` Lars Ingebrigtsen
2017-01-25 20:39 ` Peter Münster
2016-02-24 10:15 ` martin rudalics
2016-02-24 17:42 ` Eli Zaretskii
2016-02-24 18:16 ` martin rudalics
2016-02-24 18:49 ` martin rudalics
2016-02-24 20:27 ` Eli Zaretskii
2016-02-25 8:07 ` Peter Münster
2016-02-25 10:06 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87egc0noyf.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=18522@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=pmlists@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).