unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Thierry Volpiatto <thievol@posteo.net>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 63861@debbugs.gnu.org
Subject: bug#63861: [PATCH] pp.el: New "pretty printing" code
Date: Thu, 08 Jun 2023 18:08:18 +0000	[thread overview]
Message-ID: <87bkhpvm35.fsf@posteo.net> (raw)
In-Reply-To: <jwvo7lqvtmr.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]


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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

  reply	other threads:[~2023-06-08 18:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02 22:50 bug#63861: [PATCH] pp.el: New "pretty printing" code Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-03  5:53 ` Eli Zaretskii
2023-06-03 18:18   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-03 18:58     ` Eli Zaretskii
2023-06-12 20:21       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-13 10:55         ` Eli Zaretskii
2023-06-16 18:26           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-17  5:39             ` Eli Zaretskii
2023-06-17 16:13               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-17 16:42                 ` Eli Zaretskii
2023-06-17 22:08                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-04  3:25     ` Visuwesh
2023-06-07 15:48       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09  3:21         ` Visuwesh
2023-06-09 14:59           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09 15:09             ` Ihor Radchenko
2023-06-09 15:26               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09 15:59                 ` Visuwesh
2023-06-09 16:04             ` Visuwesh
2023-06-05 16:12     ` Juri Linkov
2023-06-07 15:21       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-07 18:12         ` Juri Linkov
2023-06-07 19:43           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-07 14:10 ` Thierry Volpiatto
2023-06-07 15:27   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-07 16:19     ` Thierry Volpiatto
2023-06-07 21:18       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-08 16:15   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-08 18:08     ` Thierry Volpiatto [this message]
2023-06-08 22:35       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09  0:07         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-09  5:22         ` Thierry Volpiatto
2023-06-20 20:56         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkhpvm35.fsf@posteo.net \
    --to=thievol@posteo.net \
    --cc=63861@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).