org-persist-write slow when pp-use-max-width is t

[Michael Eliachevitch <m.eliachevitch@posteo.de>]

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