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

[Michael Eliachevitch]

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