From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Fraga, Eric" <e.fraga@ucl.ac.uk>
Cc: 64681@debbugs.gnu.org
Subject: bug#64681: 30.0.50; slow saving of scores when leaving an nnml group in gnus
Date: Mon, 17 Jul 2023 09:10:25 -0400 [thread overview]
Message-ID: <jwvr0p67kzs.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87ilai9276.fsf@ucl.ac.uk> (Eric Fraga's message of "Mon, 17 Jul 2023 12:01:34 +0000")
> A significant amount of time is taken saving scores, as far as I can
> tell. I use adaptive scoring. Nothing with respect to scoring has
> changed in my configuration in some time (years probably).
If you could send me your biggest scoring file I could try and reproduce
it locally.
I understand it contains private information, so you might want to
"sanitize" it first e.g. by doing a search&replace such as
C-u M-% ".+" RET "xxxx" RET
[ Maybe you'll need to tweak the regexp, e.g. if you have strings that
contain the double quote character or that span more than one line.
E.g. maybe search for \" before doing the above. If you need more
help with that, let me know. ]
> The offending function appears to be "lisp--local-defform-body-p" with
> large memory and cpu use.
Indeed.
> After discussion on the gnus mailing list, the culprit would appear to
> be the pretty-printing. Setting pp-default-function to 'pp-28 instead
> of 'pp-fill restores the behaviour to what is desirable in terms of
> speed.
Yup, the underlying difference is that the new `pp-fill` uses
`lisp-indent-line` whereas the old code (`pp-28`) uses
`lisp-indent-region`. In most cases, the algorithmic complexity of
calling `lisp-indent-line` on every line of a region should be the same
as that of `lisp-indent-region`, but sometimes performance bugs creep
in :-(
Stefan
prev parent reply other threads:[~2023-07-17 13:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-17 12:01 bug#64681: 30.0.50; slow saving of scores when leaving an nnml group in gnus Fraga, Eric
2023-07-17 13:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
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=jwvr0p67kzs.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=64681@debbugs.gnu.org \
--cc=e.fraga@ucl.ac.uk \
--cc=monnier@iro.umontreal.ca \
/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).