Re: master 2f181d60323 3/6: pp.el (pp-fill): New default pp function

[Stefan Monnier]

>> 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