emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Michael Eliachevitch <m.eliachevitch@posteo.de>
To: Org Mode <emacs-orgmode@gnu.org>
Subject: org-persist-write slow when pp-use-max-width is t
Date: Thu, 20 Oct 2022 21:46:07 +0000	[thread overview]
Message-ID: <87o7u6t9sm.fsf@posteo.de> (raw)

I was wondering why kill-emacs emacs takes over a minute and after some profiling I found out that the call to org-persist-write-all takes long when pp-use-max-width is set to t and pp-max-width is also set (in my case to t, the window-width), which enables line folding in pp. The pp-call happens in org-persist--write-elisp-file when it is called by org-persist-write:index with the pp-parameter set to t. Maybe it's clearer with the following excerpt of my CPU-profile:

       38009  96%      - org-persist-write-all
       38009  96%       - org-persist-write
       37703  95%        - mapcar
       37703  95%         - #<compiled 0x42bf9b75c0e2209>
       37703  95%          - org-persist-write:index
       37703  95%           - org-persist--write-elisp-file
       37703  95%            - pp
       37703  95%             - pp-to-string
       37703  95%              - pp-emacs-lisp-code
       37687  95%               + pp--insert-lisp

Setting pp-use-max-width to nil made the function call almost instantanteous.

I had enabled pp-use-max-width in the past when pretty-printing the results of interactive elisp sessions (like pp-eval-last-sexp). I didn't think this would affect how other packages would save their data and I didn't expect this would result in such a performance hit. Possibly this is not an issue with org-mode or pp but just my own mistake of not being aware that pp is used as a library by other packages and thus customizing its behaviour has global effects.

Not sure if the org mailing list is the best place to report this observation. What org could do is to use a let-binding to temporarily set pp-use-max-width to nil to disable line folding. Or do you think that some users might care that their cache files are formatted prettily according to their customization options?

If you think this is not an issue with org-mode, maybe I/we could forward this to the pp-maintainers, as it's in emacs core possibly to emacs-devel? I think at least a warning in the variable documentation about performance hits might have been helpful.

Best regards,
Michael Eliachevitch

next             reply	other threads:[~2022-10-20 22:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 21:46 Michael Eliachevitch [this message]
2022-10-21  4:09 ` org-persist-write slow when pp-use-max-width is t Ihor Radchenko
2022-10-21 15:11   ` Michael Eliachevitch
2023-01-20  8:48     ` Ihor Radchenko

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.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7u6t9sm.fsf@posteo.de \
    --to=m.eliachevitch@posteo.de \
    --cc=emacs-orgmode@gnu.org \
    /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

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.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).