[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63861: [PATCH] pp.el: New "pretty printing" code
From: |
Thierry Volpiatto |
Subject: |
bug#63861: [PATCH] pp.el: New "pretty printing" code |
Date: |
Thu, 08 Jun 2023 18:08:18 +0000 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> This is comparing "the old pp-buffer" with "the new `pp-region`", using
> the patch below. This is not using your `tv/pp-region` code.
>
> I find these results (mine) quite odd: they suggest that my `pp-region`
> is *faster* than the old `pp-buffer` for `load-history` and `bookmark-alist`
> data, which I definitely did not expect (and don't know how to explain
> either).
Hmm, don't know, I ran pp-buffer with M-: from the test-load-history.el or the
test-bookmark-alist.el buffer. May be using emacs --batch makes a
difference? is the data really printed in such case?
More or less the code using pp-region takes between 42 to 48s and the one
with old pp-buffer around 6s.
Also sorry about your last patch I tested it too fast, it is indeed
slightly faster, but not much: 42 vs 46s.
> These tests were run on a machine whose CPU's speed can vary quite
> drastically depending on the load, so take those numbers with a grain of
> salt, but the dynamic frequency fluctuations shouldn't cause more than
> a factor of 2 difference (and according to my CPU frequency monitor
> widget, the frequency was reasonably stable during the test).
Yes, sure, more or less it is the same.
>> For describe variable I use a modified version of `pp` which is very
>> fast (nearly instant to pretty print value above) but maybe unsafe with
>> some vars, didn't have any problems though, see
>> https://github.com/thierryvolpiatto/emacs-config/blob/main/describe-variable.el.
>
> So, IIUC the numbers you cite above compare my `pp-region` to your
> `tv/pp-region`, right?
Not in the first mail, but after yes.
> And do I understand correctly that `tv/pp-region` does not indent its
> output?
No, it does indent, see function tv/pp which use pp-to-string which use
pp-buffer
and pp-buffer indent the whole sexp at the end.
> What was the reason for this choice?
Because indentation is done at the end by pp-buffer.
PS (unrelated to pp-region): About the old pp-buffer, there is a difficult to
find bug where the
same operation is running twice (newline is added, then removed, then
added again and then the loop continue)
You can see it by edebugging pp-buffer on a simple alist like this:
(defvar bar '((1 . "un") (2 . "deux") (3 . "trois") (4 . "quatre") (5 . "cinq")
(6 . "six")))
--
Thierry
signature.asc
Description: PGP signature
- bug#63861: [PATCH] pp.el: New "pretty printing" code, (continued)
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Visuwesh, 2023/06/09
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Juri Linkov, 2023/06/05
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/07
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Juri Linkov, 2023/06/07
- bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/07
bug#63861: [PATCH] pp.el: New "pretty printing" code, Thierry Volpiatto, 2023/06/07
bug#63861: [PATCH] pp.el: New "pretty printing" code, Stefan Monnier, 2023/06/08