bug#36566: 27.0.50; debug is sometimes horribly slow

[Lars Ingebrigtsen <larsi@gnus.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> How 'bout using a `print-char-length` limit after which we truncate?
> The truncation could "respect trees" in the sense that we'd truncate
>
>     (((a b c) (d e f) (g h k)))
>
> to something like
>
>     (((a b c) (d e ...) ...))
>
> rather than to
>
>     (((a b c) (d e ...
>
> if the `print-char-length` is 14.
>
> I suspect that with such a limit we should eliminate "all" performance
> issues, because printing should then have a complexity
> O(print-char-length) rather than O(sizeof(object)), except for the
> `print--preprocess` part which would still be O(sizeof(object)), but
> since that one is all written in C (and performs a lot less work) the
> constant is such much lower that it rarely dominates.

Hm...  that sounds really attractive, I think.  I'm trying to think of
any circumstances I'd rather see the current print-length algo instead
of this one, and I'm coming up blank.  😀

The only issue is "oh no, not yet another printing variable" (that
people will be setting to 14 in ~/.emacs and then everything that does
`prin1' to write out data will fail).

I did suggest (in conjunction with another bug report in this area) that
we should just extend `prin1{,-to-string}' with a parameter that would
set (on the C level) an equivalent variable.  So we'd have
(prin1 object fun `((char-length . ,edebug-print-char-length)))
etc.  (And `t' would be "all defaults".)

Perhaps I should just implement that stuff first.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no