From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: emacs-devel@gnu.org
Subject: Re: master 2f181d60323 3/6: pp.el (pp-fill): New default pp function
Date: Sat, 15 Jul 2023 11:19:28 -0400 [thread overview]
Message-ID: <jwv5y6lcj2r.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87ilal51qi.fsf@web.de> (Michael Heerdegen's message of "Sat, 15 Jul 2023 04:48:21 +0200")
>> Indeed, I think we'll burp then. I'll take a look at that.
> Thanks. I would vote for silently ignoring and falling back to default
> indentation.
Indeed.
> BTW, we had a thread in the Gnus mailing list
> (info-gnus-english@gnu.org) about `pp-fill'. Now that it's the default
> pp behavior, Gnus score files will be filled using this function before
> saving. I don't use score files, could be using this function is not
> appropriate for this kind of data.
I'm always ambivalent about the use of `pp` for "internal data files"
like these. I suspect they'd often be better served with a plain
`prin1`, but I'd be interesting to hear the motivation behind the use
of `pp`.
> Anyway, a user reported a massive slowdown after you had made that
> change (thread "slow saving of scores when leaving a virtual (nnml+)
> group"), and posted this profiler output:
>
> | Cpu report (partly expanded):
> |
> | 10133 79% - command-execute
> | 8519 66% - funcall-interactively
> | 4767 37% - gnus-summary-exit
> | 4659 36% - gnus-score-save
> | 4655 36% - gnus-pp
> | 4655 36% - pp
> | 4655 36% - pp-to-string
> | 4655 36% - pp-fill
> | 4647 36% - pp--object
> | 4627 36% - pp-fill
> | 4615 36% - pp-fill
> | 4555 35% - pp-fill
> | 4263 33% - pp-fill
> | 4243 33% - indent-according-to-mode
> | 4243 33% - lisp-indent-line
> | 4163 32% - calculate-lisp-indent
> | 4163 32% - lisp-indent-function
> | 4163 32% lisp--local-defform-body-p
> | 48 0% + lisp-ppss
> | 240 1% + indent-according-to-mode
> | 72 0% + gnus-run-hooks
> | 32 0% + gnus-close-group
> | 4 0% + gnus-summary-update-info
> | 3688 28% + gnus-topic-select-group
> | 60 0% + file-notify-handle-event
> | 3 0% + execute-extended-command
> | 1614 12% + byte-code
> | 2260 17% Automatic GC
> | 407 3% + timer-event-handler
> | 0 0% ...
Hmm... that looks bad, indeed, and looks (again) like a performance
problem in `lisp-indent-line`.
More specifically the `lisp--local-defform-body-p` up there suggests the
problem was introduced by the special indentation rules for `cl-flet`.
> Dunno if it is interesting for you. So far I don't know how the data
> looked like, but we can request it from the user.
That would be nice, yes. Opening an Emacs bug report for it would make
a lot of sense as well.
> After changing `pp-default-function' to 'pp-28' the user is happy.
If Gnus doesn't want to use `prin1` than maybe it should use `pp-28` or
even some other/new alternative designed for "fast pp of data": we
should be able to go significantly faster than `pp-28`. E.g. we could
forgo indentation altogether and only insert \n at appropriate places,
which would not only be fast but result is smaller files.
Stefan
next prev parent reply other threads:[~2023-07-15 15:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <168703958196.28351.5331986860123726819@vcs2.savannah.gnu.org>
2023-06-18 16:02 ` master updated (cd8d3f3379e -> 1b0348d9593) Michael Albinus
2023-06-18 18:28 ` Stefan Monnier
2023-06-18 18:30 ` Eli Zaretskii
2023-06-18 18:39 ` Eli Zaretskii
2023-06-18 21:39 ` Jim Porter
[not found] ` <20230617220622.EC118C1925A@vcs2.savannah.gnu.org>
2023-07-14 3:31 ` master 2f181d60323 3/6: pp.el (pp-fill): New default pp function Michael Heerdegen
2023-07-14 4:57 ` Stefan Monnier
2023-07-15 2:48 ` Michael Heerdegen
2023-07-15 15:19 ` Stefan Monnier [this message]
2023-07-17 9:58 ` Eric S Fraga
2023-07-17 12:24 ` Eric S Fraga
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=jwv5y6lcj2r.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=michael_heerdegen@web.de \
/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).