[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36566: 27.0.50; debug is sometimes horribly slow
From: |
Lars Ingebrigtsen |
Subject: |
bug#36566: 27.0.50; debug is sometimes horribly slow |
Date: |
Sat, 14 May 2022 17:45:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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
- bug#36566: 27.0.50; debug is sometimes horribly slow, Gemini Lasswell, 2022/05/13
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/13
- bug#36566: 27.0.50; debug is sometimes horribly slow, Michael Heerdegen, 2022/05/13
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/14
- bug#36566: 27.0.50; debug is sometimes horribly slow, Stefan Monnier, 2022/05/14
- bug#36566: 27.0.50; debug is sometimes horribly slow,
Lars Ingebrigtsen <=
- bug#36566: 27.0.50; debug is sometimes horribly slow, Stefan Monnier, 2022/05/14
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/14
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/14
- bug#36566: 27.0.50; debug is sometimes horribly slow, Stefan Monnier, 2022/05/14
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/15
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/15
- bug#36566: 27.0.50; debug is sometimes horribly slow, Stefan Monnier, 2022/05/15
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/15
- bug#36566: 27.0.50; debug is sometimes horribly slow, Stefan Monnier, 2022/05/15
- bug#36566: 27.0.50; debug is sometimes horribly slow, Lars Ingebrigtsen, 2022/05/15