From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.bugs Subject: bug#63861: [PATCH] pp.el: New "pretty printing" code Date: Thu, 08 Jun 2023 18:08:18 +0000 Message-ID: <87bkhpvm35.fsf@posteo.net> References: <87edmnics1.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27498"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63861@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 08 20:36:15 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q7KUY-0006yt-J4 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Jun 2023 20:36:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7KUR-00058L-JL; Thu, 08 Jun 2023 14:36:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7KUN-00055k-DM for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 14:36:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q7KUN-0007y6-5C for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 14:36:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7KUN-00025u-1a for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 14:36:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thierry Volpiatto Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Jun 2023 18:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63861 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org Original-Received: via spool by 63861-submit@debbugs.gnu.org id=B63861.16862493428006 (code B ref 63861); Thu, 08 Jun 2023 18:36:03 +0000 Original-Received: (at 63861) by debbugs.gnu.org; 8 Jun 2023 18:35:42 +0000 Original-Received: from localhost ([127.0.0.1]:57539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7KU1-00024z-EG for submit@debbugs.gnu.org; Thu, 08 Jun 2023 14:35:41 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:60457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7KTw-00024g-Fu for 63861@debbugs.gnu.org; Thu, 08 Jun 2023 14:35:39 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id EDC93240028 for <63861@debbugs.gnu.org>; Thu, 8 Jun 2023 20:35:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1686249331; bh=bn0HBf9ch96YnPIDc7xLGnbCg6b3a/Ooa0haqxrCnaE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=NnflgKhwz509s7qjhAtlJqrKy4HE1scV0FPuKm2LgDHpVSrwI5Vv3EXeRWNVCeGx4 UWVxhDuecF0cuRfo/QtO34KQCN1mLKV+rM5nX7IFjqBMdju5y7RAo7LXgVHlpURBjx too3y/ACGJG2pSgcMduLpM0NI8AIJh+oz6gE/EU2WooeCfkXwFTTKw/wtx9i+UEf0U 7tJ3lXmFGYoSyzXOVUwx2qTd572Fy219K0yNylJ7e0v2OnkfIxQyCW+JTSuUn4/1nX BAjgJy4gMRD1vxkO83HwZNmXh2Txyf+aTdA+bCeiZU8B1b+feQFwTdSxcYWxKCXAiq fsabwOTOQRu+w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QcXvj525xz9rxV; Thu, 8 Jun 2023 20:35:29 +0200 (CEST) In-reply-to: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263138 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Stefan Monnier 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-ali= st` > 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-vari= able.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 . "ci= nq") (6 . "six"))) =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmSCH24THHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvkw+fC/sFPgkM9RlaUeWC3RkW5rGlE8l+ebPb stAyBMFL4kON1t6p/htBv/9ljl2nBmMK0dszhFvM/m0UkWByBtmupQNBL3zke5Je cgqu4MMRqqKejXdAzAolF2uEQwTB2leb7AYTWzzRFjyAryfONaQcq4pGYJvsaqCC O1rwCkmzU8fnZR2Gc0eb8wJxBDoBExhAQVMU8JNJ4K5oTLAKrO/n3PVg6GrZ19Ni uKTJsV33udqPTIqFsjDdRN5cNQiDc63g2aaMobJ7Zahh9LPS5oFeRSCIOms/tDR1 BRj3FCziJP1IJvXTyeVfTskZ2626mTyLBilJkqtTedRbV9l3lfnKyBZpgfrWYUKH Grkt5hGWLPSyj6boyGr6LGpZw3e4xs/aFkcCoxRBCW9pTflW/z6Wzg4THz9xm4Il hTv/ZHxNT4xP3N0oArA/UiDdNH7Cu7CUAOi4jd4lFZs4XRlNUVWwfW+QD7bpftzV 2CRK08x3FiYjqrrK7dcvD86xYIdwk/onylE= =KTPc -----END PGP SIGNATURE----- --=-=-=--