bug-gnu-emacs
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]