From unknown Fri Jun 20 05:37:29 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#25122 <25122@debbugs.gnu.org> To: bug#25122 <25122@debbugs.gnu.org> Subject: Status: 24.5; function describe-variable hangs on large variables Reply-To: bug#25122 <25122@debbugs.gnu.org> Date: Fri, 20 Jun 2025 12:37:29 +0000 retitle 25122 24.5; function describe-variable hangs on large variables reassign 25122 emacs submitter 25122 Boruch Baum severity 25122 minor tag 25122 patch fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 21:20:28 2016 Received: (at submit) by debbugs.gnu.org; 6 Dec 2016 02:20:28 +0000 Received: from localhost ([127.0.0.1]:57519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cE5Mm-0003Lb-Q6 for submit@debbugs.gnu.org; Mon, 05 Dec 2016 21:20:28 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cE5Ml-0003LQ-NQ for submit@debbugs.gnu.org; Mon, 05 Dec 2016 21:20:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cE5Mf-0002lF-5Q for submit@debbugs.gnu.org; Mon, 05 Dec 2016 21:20:18 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:37923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cE5Mf-0002l9-2H for submit@debbugs.gnu.org; Mon, 05 Dec 2016 21:20:17 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cE5Md-0001lL-68 for bug-gnu-emacs@gnu.org; Mon, 05 Dec 2016 21:20:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cE5MZ-0002kZ-W6 for bug-gnu-emacs@gnu.org; Mon, 05 Dec 2016 21:20:15 -0500 Received: from mout.gmx.net ([212.227.15.19]:54519) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cE5MZ-0002jg-Ml for bug-gnu-emacs@gnu.org; Mon, 05 Dec 2016 21:20:11 -0500 Received: from E15-2016.optimum.net ([108.6.168.221]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0Llmcq-1cnQBE0zZI-00ZM09 for ; Tue, 06 Dec 2016 03:20:08 +0100 Date: Mon, 5 Dec 2016 21:21:12 -0500 From: Boruch Baum To: Emacs Bug Reporting Subject: 24.5; function describe-variable hangs on large variables Message-ID: <20161206022112.GF25778@E15-2016.optimum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:SEwWsPShjmRm571C7D60ZkVelvT/Zt55DxBV3F8MPmV/prTo56c PJtBRnb8Ryd2tM3NVnW2IP+fPiD+1tvJdTuJ4Nk+AeY21rW0l8ASk6byq3uX/5WqcV/3glp q3jz0aLTQuXA/49eSYgFMsq1PZLgCEjNM3RSUREyofhYzOqf3/Z33E2K8gsXpoZFPtYR0+C tAPlxS1mV1CX5ZrruC/hw== X-UI-Out-Filterresults: notjunk:1;V01:K0:EDwz+/f/8ts=:j7DJEqOJ3oUKsEyk3qdJXh JbY4Asg5w9L7+AeAf3DEAcLHcAmOjocuGHwwqBHxNbNv8KwZVh0rfcLiDKusJzgOd90vqjKjg V7uEzl3H/QwU6B/0k4LM4P215761Ugqqp5G1Np6bb1p9Wfbz3PMGW/obO14JJyaflwTUP7MXK BgD9mW0eBT/p6NaGOAS5nBxq+ZYwDNr27wzIdRapco0QEIKfJyeUYj0GuX7hmWQgC+EykwcpG LPqjtd79MMZAGvFZO/3aPpGuaaiMbe1UnNhQPJTmv8JLCWlAmHmGDjwRPWgx5nAsN4BBiz42T +aYlH99RpoMwcaUWmLEr8N5SFteLfBhn+recMv/j0tntbvCDxn/WVA0pMuoXnuANhDaXVBZcs px5b8nyCvsk87dgVCEe2k8c0igtwFbAsbJuykTyCGCdnVnmLrnyHPU7beVRPXJC5uvuYqHWXV Ki5ToGajuInvRCwfk9DxsBL8stxGtp2FcAOt++qKv9Qxzg/gVKXLjA5jVveMfvWmP86BEAe6H 4plbboqZkPlJkp5Wvx/e7hna41XugSpiwhFgdoepvIM36QD4lt+pSsLD+yURde4g6w7UezFGm 0xaiLIM5h9rARxbh7Mw4xihQ/C4UK955UuhkMqq50wbNXOVHizPhN/Q/ylrg52ASqeG/nFJvo mGanmg0W+iTdXJP5YxYYeoAf2r4rJeqoEwADHeACXszy1JxAX/0bfm8Tvw0S6pxM4jLcf7ldL whX4trsB/Boo2oLyOZzvIxcUkk1kZ5cezGGysbBxAAdcAiuhgQNq2cMgAn8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) Subject: 24.5; function describe-variable hangs on large variables 1) When evaluating function describe-variable for variable package-archive-conteqnts, emacs hangs for minutes before I gave up. 2) Aborting vua C-g works. 3) Viewing the buffer list revealed that a *Help* buffer had begun to be created. Its content was "package-archive-contents is a variable defined in `package.el'. Its value is " (new-lines removed). 4) If emacs is trying to stuff into that variable (and into that *Help* buffer) all the archive information from the archive files of my ~/.emacs.d/elpa/archives/ tree, that would be about 730kb of elisp. In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu) of 2016-03-19 on trouble, modified by Debian System Description: Devuan GNU/Linux 1.0 (jessie) Configured using: `configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp --with-x=no --without-gconf --without-gsettings 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: global-anzu-mode: t anzu-mode: t ws-butler-mode: t dtrt-indent-mode: t clean-aindent-mode: t yas-minor-mode: t global-undo-tree-mode: t undo-tree-mode: t volatile-highlights-mode: t global-ede-mode: t ede-minor-mode: t global-semantic-idle-scheduler-mode: t global-semanticdb-minor-mode: t async-bytecomp-package-mode: t global-semantic-stickyfunc-mode: t semantic-mode: t helm-mode: t shell-dirtrack-mode: t projectile-mode: t global-company-mode: t company-mode: t override-global-mode: t winner-mode: t show-paren-mode: t savehist-mode: t desktop-save-mode: t delete-selection-mode: t tooltip-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Features: (shadow sort mail-extr eieio-opt emacsbug helm-command tramp-cache conf-mode org-element org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view image-mode org-bibtex bibtex org-bbdb org-w3m misearch multi-isearch zygospore sh-script smie executable setup-editing help-macro sgml-mode iedit-lib rect anzu mule-util ws-butler benchmark dtrt-indent clean-aindent-mode yasnippet undo-tree diff volatile-highlights ede/cpp-root ede/emacs setup-cedet ede/speedbar ede/files ede ede/base ede/auto ede/source eieio-speedbar speedbar sb-image dframe eieio-custom wid-edit semantic/idle semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt semantic/db-mode semantic/db eieio-base cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs setup-helm-gtags helm-gtags subr-x pulse which-func setup-helm helm-projectile helm-config async-bytecomp helm-imenu semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local cedet org org-macro org-footnote org-pcomplete org-list org-faces org-entities noutline outline org-version ob-sh ob-awk ob-latex ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs imenu helm-easymenu helm-mode helm-elisp helm-files tramp tramp-compat tramp-loaddefs trampver shell pcomplete ffap helm-buffers helm-tags helm-bookmark helm-locate helm-eval edebug eldoc helm-grep helm-regexp helm-elscreen helm-adaptive helm-info info helm-types helm-external helm-net browse-url xml helm-utils helm-help helm helm-source helm-multi-match helm-lib smtpmail sendmail async setup-general windmove projectile skeleton grep ibuf-ext thingatpt json epl rx company-oddmuse company-keywords company-etags company-gtags company-dabbrev-code company-files company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-css company-nxml company-bbdb tempo ispell etags find-func company-dabbrev company-template company tar-mode use-package cl diminish bind-key compile comint tool-bar autoload lisp-mnt finder-inf mm-archive message rfc822 mml mml-sec mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils gnutls network-stream starttls url-http tls mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw url-cache url-auth url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers url-parse auth-source eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core gnus-util mm-util mail-prsvr password-cache url-vars epg xterm server warnings dired-details+ dired-details help-mode advice help-fns dired+ image-dired image-file image dired-x dired-aux dired winner ring pcase git-blame format-spec package epg-config bookmark cl-macs gv derived pp jka-compr ibuf-macs ibuffer paren woman man easymenu regexp-opt ansi-color edmacro kmacro time-date savehist desktop frameset cl-loaddefs cl-lib elec-pair delsel tango-dark-theme debian-el debian-el-loaddefs w3m-load emacs-goodies-el emacs-goodies-custom emacs-goodies-loaddefs easy-mmode devhelp tooltip electric uniquify ediff-hook vc-hooks lisp-float-type tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify multi-tty emacs) Memory information: ((conses 16 582332 490741) (symbols 48 55652 20) (miscs 40 421 1843) (strings 32 146045 231132) (string-bytes 1 4264772) (vectors 16 55051) (vector-slots 8 1598839 288778) (floats 8 286 3294) (intervals 56 4525 912) (buffers 960 27) (heap 1024 62515 75886)) -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 06 01:41:38 2016 Received: (at submit) by debbugs.gnu.org; 6 Dec 2016 06:41:38 +0000 Received: from localhost ([127.0.0.1]:57574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cE9Ra-0000wi-7o for submit@debbugs.gnu.org; Tue, 06 Dec 2016 01:41:38 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cE9RX-0000wU-4D for submit@debbugs.gnu.org; Tue, 06 Dec 2016 01:41:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cE9RR-0008KA-09 for submit@debbugs.gnu.org; Tue, 06 Dec 2016 01:41:29 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:37995) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cE9RQ-0008K5-TW for submit@debbugs.gnu.org; Tue, 06 Dec 2016 01:41:28 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cE9RP-0003Uc-U9 for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2016 01:41:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cE9RM-0008Jf-T5 for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2016 01:41:28 -0500 Received: from [195.159.176.226] (port=49200 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cE9RM-0008JR-M8 for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2016 01:41:24 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cE9RF-0003H7-C2 for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2016 07:41:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables Date: Tue, 06 Dec 2016 07:41:13 +0100 Lines: 33 Message-ID: <87twahk19y.fsf@gmail.com> References: <20161206022112.GF25778@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@blaine.gmane.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cancel-Lock: sha1:bEcEURdXTh9gW33ilAFntleJ7AE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Boruch Baum writes: > Subject: 24.5; function describe-variable hangs on large variables > > 1) When evaluating function describe-variable for variable > package-archive-conteqnts, emacs hangs for minutes before I gave up. I have already reported this bug. I use this to workaround it: (progn ;; Speedup `describe-variable' for variables with huge value description. (defun tv/describe-variable (old-fn &rest args) ;; `cl-flet' can't be used here because `pp' should ;; appear lexically in its body, which is not the case. ;; Using `flet' is an option, but even better is binding ;; (symbol-function 'pp) with `cl-letf'. (cl-letf (((symbol-function 'pp) (lambda (object &optional stream) (let ((fn (lambda (ob &optional stream) (princ (pp-to-string ob) (or stream standard-output)) (terpri))) (print-circle t)) (if (consp object) (progn (insert "\n(") (mapc fn object) (cl-letf (((point) (1- (point)))) (insert ")"))) (funcall fn object stream)))))) (apply old-fn args))) (advice-add 'describe-variable :around #'tv/describe-variable)) From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 06 11:46:24 2016 Received: (at control) by debbugs.gnu.org; 6 Dec 2016 16:46:24 +0000 Received: from localhost ([127.0.0.1]:58434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEIsp-0001ay-R9 for submit@debbugs.gnu.org; Tue, 06 Dec 2016 11:46:23 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEIso-0001an-In for control@debbugs.gnu.org; Tue, 06 Dec 2016 11:46:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEIsf-0001QP-ND for control@debbugs.gnu.org; Tue, 06 Dec 2016 11:46:17 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEIsf-0001QL-Jv for control@debbugs.gnu.org; Tue, 06 Dec 2016 11:46:13 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1cEIsf-0005oT-99 for control@debbugs.gnu.org; Tue, 06 Dec 2016 11:46:13 -0500 Subject: control message for bug 25122 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Tue, 06 Dec 2016 11:46:13 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.0 (--------) forcemerge 21717 25122 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 06 22:49:54 2016 Received: (at 25122) by debbugs.gnu.org; 7 Dec 2016 03:49:54 +0000 Received: from localhost ([127.0.0.1]:58678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cETEw-0001VO-54 for submit@debbugs.gnu.org; Tue, 06 Dec 2016 22:49:54 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:34975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cETEu-0001V7-J8; Tue, 06 Dec 2016 22:49:52 -0500 Received: by mail-io0-f193.google.com with SMTP id h133so25679279ioe.2; Tue, 06 Dec 2016 19:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=fOUiZOxPeB0yjhSpA/vp9gH6BJ502VIMjT5X31O30lY=; b=BOjar0fTigaemD2PpzBblHytioOYTrCkMdGVSZ5YJW0cLS15gHgjvsehA6ir7vziUt ilDkhaZcAm/CSm7UoiePjlSRbXvj9JxyhfZyuBfKrJ3pQtUQHJtPd6EglXQ2b0+g07Iz s97XT3IA+jYKHtF/S7ljpvHidZQ06W1mETvvoiBZBpwuflV44inQKHNCOPGBhdfH41Jn r0drHKI2tr5ysq0L82cH0kNN8bI09rlWGUWJpjhUNZz0T6+kHqUUYIB3z+2cG73RVjcb CTFQ7BpFuiFtoJiHakVbLGUgpfyqIZvnu6IElELWWuS8sb6ZjWn3SHZofP871z1oDgk6 2Sag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=fOUiZOxPeB0yjhSpA/vp9gH6BJ502VIMjT5X31O30lY=; b=AzmV/NSoj78x6j+ioyRjoKVPOvttN1KLhwOxuEiqtdqFezJmCPBGhOr90Jtbcul9Bi DEvUajM5SrqCgkwU/QHWlKBM6VpljR4E7i8AW4fCUR28ZxvitGEsEnKUdJQ+LaHkZWS9 qxzZo9oNOpeLt8XVzpUYP7iVfHGn6ONRePa6a7ylE0eIpwSvyVzjj08c2kc1woDDBvR7 l7PHyZOj8jckIHH8Sap5uMKHHvviKa3QrL3LXZjA8KecUusHp14xErSUmx/WW7nSG6nt Uvwqn/W2nm1oXACfi+NYG3FLVPIVbWOedM9Of3rfRGCBms2RnTUfKhGYbCvtuIxvUSsf 6lhw== X-Gm-Message-State: AKaTC00txrM+UisMmVJM0ncBdwmIgDHWeAx+WZB3B5jwxM7sVRLKq8I+f7WSXsAfop1Ftg== X-Received: by 10.36.127.84 with SMTP id r81mr548332itc.57.1481082587067; Tue, 06 Dec 2016 19:49:47 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id 9sm2753553itv.0.2016.12.06.19.49.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 06 Dec 2016 19:49:46 -0800 (PST) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> Date: Tue, 06 Dec 2016 22:50:46 -0500 In-Reply-To: <87twahk19y.fsf@gmail.com> (Thierry Volpiatto's message of "Tue, 06 Dec 2016 07:41:13 +0100") Message-ID: <87d1h4fld5.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) merge 13439 25122 quit Thierry Volpiatto writes: > Boruch Baum writes: > >> Subject: 24.5; function describe-variable hangs on large variables >> >> 1) When evaluating function describe-variable for variable >> package-archive-conteqnts, emacs hangs for minutes before I gave up. > > I have already reported this bug. > I use this to workaround it: I wonder if the suggestion in #13439 might also help? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 07 03:58:37 2016 Received: (at 25122) by debbugs.gnu.org; 7 Dec 2016 08:58:37 +0000 Received: from localhost ([127.0.0.1]:58826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEY3h-0003v3-D8 for submit@debbugs.gnu.org; Wed, 07 Dec 2016 03:58:37 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cEY3f-0003ur-DX for 25122@debbugs.gnu.org; Wed, 07 Dec 2016 03:58:36 -0500 Received: by mail-wm0-f67.google.com with SMTP id g23so26445137wme.1 for <25122@debbugs.gnu.org>; Wed, 07 Dec 2016 00:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=6gNhf2UYVvBXw9VMo8/Jp5tPX8t856BFDclF3MmyX6Q=; b=WAfR0NvLcI90CrOV64o/FieOPkbEspXyYQl/vteWh74RHoQyOpFk11bDGln2NS8PfT SgZLu7qJjVgzfEB87dUWXcdyUkqzKThNLKeeyPgu1rLaIt+Un+tzP0ruuEvSnmxjNDaJ MqrO9wPbdTo8oyk0rB6HSf87kvcoCvJQZcZzcUVhBOu6GEZfgBHCu/m6xD6jdGrWK1R6 2Fgxn660tvWVUhTGqRdBMpjaLnq9XTpfZLxAd51Qwlo41giPVXhQHHalnRbSyXcOi/u6 crxWHZnR1SEzL/y08c9rGzLjGkqkjIH4CkZTAb4lA4uK4uhl6tMYXS+1T0LIpH/jIN7Z KBFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=6gNhf2UYVvBXw9VMo8/Jp5tPX8t856BFDclF3MmyX6Q=; b=NCDquYqvRhHmIvq6CCMEfxqLsZCD0mo4h26nsS5pVZlSYtlP0BFdoGBV122gsUvkt3 //UmZmR5mFZMZiRP/EBDdkfkHmTlLzK0Ajy4nIfbeMhbEeml4ptW9hQ4joRmoXVPK8PZ fk55GawLZvsQO0AiXoJGpF3QYw5UDxYcNOieb53jTzrKaGXI//3BFoKC29K6sm+QyE5O e47QSUFf+fmrvBal241Mweg7lwNfVfd84x81KqTQzR479F7LRDKZLGSX/+dobGBd+96o u1Ljtj5qmNgHQJd9vGHUePiJ4tElIP9u0v+ZwXPg+DNs7mBUva0AowC6hzZSLxYf39RY Iaag== X-Gm-Message-State: AKaTC00QoOYbPLjOAJjKKhC6pdbF5ctnlEKyaO/IWNPGCnjCDk1wt7rBEmI1xblaiSdZpg== X-Received: by 10.28.221.11 with SMTP id u11mr1565816wmg.123.1481101109652; Wed, 07 Dec 2016 00:58:29 -0800 (PST) Received: from dell-14z ([37.166.7.104]) by smtp.gmail.com with ESMTPSA id cl6sm30193900wjc.10.2016.12.07.00.58.28 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 07 Dec 2016 00:58:28 -0800 (PST) References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> User-agent: mu4e 0.9.17; emacs 26.0.50.5 From: Thierry Volpiatto To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables In-reply-to: <87d1h4fld5.fsf@users.sourceforge.net> Date: Wed, 07 Dec 2016 09:58:25 +0100 Message-ID: <871sxkyv2m.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) npostavs@users.sourceforge.net writes: > merge 13439 25122 > quit > > Thierry Volpiatto writes: > >> Boruch Baum writes: >> >>> Subject: 24.5; function describe-variable hangs on large variables >>> >>> 1) When evaluating function describe-variable for variable >>> package-archive-conteqnts, emacs hangs for minutes before I gave up. >> >> I have already reported this bug. >> I use this to workaround it: > > I wonder if the suggestion in #13439 might also help? I don't think it would be as fast as printing one by one each elements. What is slow is printing the whole object. See how bookmark file is saved, it was taking more than one minute for my bookmarks before printing one by one, now it is instant or nearly. -- Thierry From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 00:38:56 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 05:38:56 +0000 Received: from localhost ([127.0.0.1]:50178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmZjy-0006qg-Uk for submit@debbugs.gnu.org; Sat, 11 Mar 2017 00:38:56 -0500 Received: from mail-it0-f44.google.com ([209.85.214.44]:38373) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmZjw-0006qN-Lh for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 00:38:53 -0500 Received: by mail-it0-f44.google.com with SMTP id m27so7905907iti.1 for <25122@debbugs.gnu.org>; Fri, 10 Mar 2017 21:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=WmDp4YuoB/ykfbjpfi7PuD6YaldbY5JYVjwhHMg4jBk=; b=YW4BTb2UFN8JpAwn1+KmFX62D8wTLC0QTnDMXVar/xvH8O/QLqFPYWQtTw8m3I2fiL FQaPoGyUM/Zaoit2FXB9wSyYhoFC754HzdNFfchjs9IfmLAk2brv8TC+DNMG70UU5DJG D6RPDLjQn1F50T00i1lNoVd0SdRC9dT7Bi6XuNHGpxUMljah+laOi7+FTfoOpty8hL+H rEUjgLp2LBEXQrDEsKEC+inu74l9tTXlxgydHBw5UVte6o3lxCoOAkE8RgqDpfVXGMQv rAi6Z05JoRPorSKZMELwsSIlBXspjKv8uwgaQzepoAvcGH+58bPWZbdoy0lgYJC79JKa y0LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=WmDp4YuoB/ykfbjpfi7PuD6YaldbY5JYVjwhHMg4jBk=; b=isq0Dw7eFdJqViMfifzlxyuSdKzYnAONDSDnoKohI6Vh1GBFKbswp7Gv15UcFmQBkN cXosAUs5Ujd0AgLVODGDJC8BgYSzfAQc2HHDug6BVUYk7ZvOYdSIZU8S2vsgm8j2OUEi dXc+/QoO7nnpq4JgJE4ofECMBSKjlOwKh6DYem3b0CuR1mS2tY7qFZTJEmH73fXcFa4w LVCat3k/NUHA36e5E/Gnanfw26nHl9FIQaf3c1b9cfx5G1bMPNDi46fY3/i9I3o4GjD0 0gXyrz26NIpDLVSS20JTUKchl5/wkArqQ/83Wkh24kYIrJN6ZJfpQpEB4s4vI7/INV6l xwFA== X-Gm-Message-State: AFeK/H0P4dSbZCwsCwbcjkA4gQ/XTN9eSSYs4yziDBC3TP4D7QWsoxsTGc32m3p5rt9a5A== X-Received: by 10.36.116.71 with SMTP id o68mr2490419itc.60.1489210727074; Fri, 10 Mar 2017 21:38:47 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id p140sm757479itc.27.2017.03.10.21.38.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 10 Mar 2017 21:38:45 -0800 (PST) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> Date: Sat, 11 Mar 2017 00:40:03 -0500 In-Reply-To: <871sxkyv2m.fsf@gmail.com> (Thierry Volpiatto's message of "Wed, 07 Dec 2016 09:58:25 +0100") Message-ID: <87mvcs8j7w.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --=-=-= Content-Type: text/plain Thierry Volpiatto writes: > > I don't think it would be as fast as printing one by one each elements. > What is slow is printing the whole object. > See how bookmark file is saved, it was taking more than one minute for > my bookmarks before printing one by one, now it is instant or nearly. Actually, it's the indent-sexp on the whole object that takes time. Possibly we could sacrifice some indentation correctness if the printed representation is big. I've been attempting an alternate approach which prettyprints the object while scanning it instead of the current way of printing and then reindenting. Without optimizing, it's about 3 times as fast as the current pp (it's the pp-prin1 in the benchmarks below), though more than 3 times slower than your mapc pp trick. On the other hand, it also doesn't yet handle function-specific indentation or any compound structure apart from lists, so I'm not sure if it will end up being much faster. (benchmark 1 '(with-temp-buffer (pp-prin1 long-list (current-buffer)) nil)) "Elapsed time: 3.391232s (0.565806s in 11 GCs)" (benchmark 1 '(progn (pp-to-string long-list) nil)) "Elapsed time: 9.988515s (0.148034s in 3 GCs)" (benchmark 1 '(progn (with-output-to-string (mapc 'pp long-list)) nil)) "Elapsed time: 0.983493s (0.144424s in 3 GCs)" (benchmark 1 '(progn (cl-prin1-to-string long-list) nil)) "Elapsed time: 0.511617s (0.152483s in 3 GCs)" (benchmark 1 '(progn (prin1-to-string long-list) nil)) "Elapsed time: 0.029320s" --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v1-0001-Initial-draft-of-new-pretty-printer-Bug-25122.patch Content-Description: draft patch >From 66f6dda0507fa4699ba929379cd1c58ef8b540f5 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 11 Mar 2017 00:09:36 -0500 Subject: [PATCH v1] Initial draft of new pretty printer (Bug#25122) * lisp/emacs-lisp/pp.el (pp-state): New struct. (pp--scan): New function, measures length of sublists (actually "logical blocks" to allow for more customizable grouping than just by lists). Calls pp--print when scanned tokens are too wide to fit on a single line. (pp--print): New function, prints tokens horizontally or vertically depending on whether the sublist can fit within the line. (pp-prin1): New function, entry point for pp--scan and pp-print. Wraps stream so that cl-print will dispatch to prettyprinting methods. (cl-print-object) <_ (head :pprint)>: New method, wraps cl-prin1-to-string for prettyprinting. (cl-print-object) : New mthod, prettyprinter for lists. --- lisp/emacs-lisp/pp.el | 143 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index 7ef46a48bd..3809325c4b 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -24,6 +24,9 @@ ;;; Code: +(eval-when-compile (require 'cl-lib)) +(require 'ring) + (defvar font-lock-verbose) (defgroup pp nil @@ -121,6 +124,146 @@ pp-display-expression (setq buffer-read-only nil) (set (make-local-variable 'font-lock-verbose) nil))))) + +(cl-defstruct (pp-state (:constructor + make-pp-state + (stream + &aux + (right-margin fill-column) + (left-margin 0) + (indent '(0)) + (scan-depth 0) + (print-depth 0) + (print-width 0) + (scan-width 0) + (block-mode (list nil)) + (fifo (make-ring 30))))) + stream + right-margin ; how far we may go. + left-margin ; how far printer has gone + print-width ; total width of tokens printed so far. + indent ; left-margin, stack per depth. + scan-width ; total width of tokens scanned so far. + scan-depth + print-depth + block-widths + block-mode ; `:vertical', `:horizontal', nil (undecided); stack per depth. + fifo + ) + +(defun pp--print (state) + (cl-symbol-macrolet ((stream (pp-state-stream state)) + (depth (pp-state-print-depth state)) + (scan-depth (pp-state-scan-depth state)) + (fifo (pp-state-fifo state)) + (left-margin (pp-state-left-margin state)) + (width (pp-state-print-width state)) + (indent (pp-state-indent state)) + (right-margin (pp-state-right-margin state)) + (block-mode (pp-state-block-mode state))) + (catch 'rescan + (while (not (ring-empty-p fifo)) + (pcase (ring-remove fifo) + ((and `(,len . :open-block) token) + (if (<= len 0) + ;; Not ready to print this yet! + (progn (ring-insert-at-beginning fifo token) + (throw 'rescan nil)) + (cl-incf depth) + (push left-margin indent) + (push (if (> (+ left-margin len) right-margin) + :vertical :horizontal) + block-mode))) + (:close-block (cl-decf depth) (pop indent) (pop block-mode)) + (:blank + (pcase (car block-mode) + (:vertical + (terpri stream) + (princ (make-string (car indent) ?\s) stream) + (setf left-margin (car indent))) + ((or :horizontal 'nil) + (write-char ?\s stream) + (cl-incf left-margin)) + (_ (error "oops"))) + (cl-incf width)) + (:eof nil) + ((and (pred characterp) char) + (write-char char stream) + (cl-incf left-margin (char-width char)) + (cl-incf width (char-width char))) + (string + (princ string stream) + (cl-incf left-margin (string-width string)) + (cl-incf width (string-width string)))))))) + +(defun pp--scan (token state) + (cl-symbol-macrolet ((stream (pp-state-stream state)) + (depth (pp-state-scan-depth state)) + (print-depth (pp-state-print-depth state)) + (fifo (pp-state-fifo state)) + (width (pp-state-scan-width state)) + (right-margin (pp-state-right-margin state)) + (block-widths (pp-state-block-widths state))) + (cl-flet ((scanlen (len) (cl-incf width len))) + (cl-assert (> (ring-size fifo) (ring-length fifo))) + (ring-insert fifo token) + (pcase token + (:open-block + (cl-incf depth) + (let ((block-token (cons (- width) (ring-remove fifo 0)))) + (push block-token block-widths) + (ring-insert fifo block-token))) + (:close-block + (cl-incf (caar block-widths) width) + (when (> (caar block-widths) right-margin) + (pp--print state)) + (cl-decf depth) + (pop block-widths)) + (:blank (scanlen 1)) + (:eof (pp--print state)) + ((pred characterp) (scanlen (char-width token))) + (_ (scanlen (string-width token))))) + (when block-widths + (when (> (+ (caar block-widths) width) right-margin) + (dolist (block-width block-widths) + (setf (car block-width) (+ right-margin 1)))) + (when (> (caar block-widths) right-margin) + (pp--print state))))) + +(defvar cl-print-readably) ; cl-print.el + +(defun pp-prin1 (object &optional stream) + (let ((cl-print-readably nil) + (stream (make-pp-state (or stream standard-output)))) + (pp--scan :open-block stream) + (prog1 (cl-prin1 object (cons :pprint stream)) + (pp--scan :close-block stream) + (pp--scan :eof stream)))) + +;; fallback to standard `cl-print-object'. +(cl-defmethod cl-print-object (object (stream (head :pprint))) + (pp--scan (cl-prin1-to-string object) (cdr stream)) + object) + +(cl-defmethod cl-print-object ((list cons) (stream (head :pprint))) + (let ((state (cdr stream))) + (pcase list + (`(,head . ,tail) + (pp--scan "(" state) + (pp--scan :open-block state) + (cl-print-object head stream) + (while (consp tail) + (pp--scan :blank state) + (cl-print-object (pop tail) stream)) + (when tail + (pp--scan :blank state) + (pp--scan ?\. state) + (pp--scan :blank state) + (cl-print-object tail stream)) + (pp--scan :close-block state) + (pp--scan ")" state)))) + list) + ;;;###autoload (defun pp-eval-expression (expression) "Evaluate EXPRESSION and pretty-print its value. -- 2.11.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 10:22:16 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 15:22:16 +0000 Received: from localhost ([127.0.0.1]:51615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmiqW-000123-E4 for submit@debbugs.gnu.org; Sat, 11 Mar 2017 10:22:16 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:52775) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmiqT-00011p-CP for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 10:22:14 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASCQAFFcRY/3OXCkxdGgEBAQECAQEBAQgBAQEBg1FBihOFeJEHAZcfGoYCBAICgkBEFAECAQEBAQEBAWsohRYGViMQCzQSFBgNJIoTtCSKYAEBAQEGAgEliz2KOQWQWotnnHyGYpF/gUQ2IYEEIxYILIUXHoIBIoouAQEB X-IPAS-Result: A0ASCQAFFcRY/3OXCkxdGgEBAQECAQEBAQgBAQEBg1FBihOFeJEHAZcfGoYCBAICgkBEFAECAQEBAQEBAWsohRYGViMQCzQSFBgNJIoTtCSKYAEBAQEGAgEliz2KOQWQWotnnHyGYpF/gUQ2IYEEIxYILIUXHoIBIoouAQEB X-IronPort-AV: E=Sophos;i="5.36,147,1486443600"; d="scan'208";a="295032164" Received: from 76-10-151-115.dsl.teksavvy.com (HELO pastel.home) ([76.10.151.115]) by smtp.teksavvy.com with ESMTP; 11 Mar 2017 10:22:06 -0500 Received: by pastel.home (Postfix, from userid 20848) id 98CA761875; Sat, 11 Mar 2017 10:21:53 -0500 (EST) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables Message-ID: References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> Date: Sat, 11 Mar 2017 10:21:53 -0500 In-Reply-To: <87twahk19y.fsf@gmail.com> (Thierry Volpiatto's message of "Tue, 06 Dec 2016 07:41:13 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > (cl-letf (((symbol-function 'pp) > (lambda (object &optional stream) > (let ((fn (lambda (ob &optional stream) > (princ (pp-to-string ob) > (or stream standard-output)) > (terpri))) > (print-circle t)) > (if (consp object) > (progn > (insert "\n(") > (mapc fn object) > (cl-letf (((point) (1- (point)))) > (insert ")"))) > (funcall fn object stream)))))) Hmm... I wonder why this would be faster. In the past, the implementation of `print-circle` had a poor complexity, but we fixed that around Emacs-24, IIRC so it now uses a hash-table and should have O(n) complexity, which means that pp shouldn't be slower than (mapc #'pp). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 10:34:10 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 15:34:10 +0000 Received: from localhost ([127.0.0.1]:51620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmj22-0001JF-Ih for submit@debbugs.gnu.org; Sat, 11 Mar 2017 10:34:10 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmj21-0001J2-N0 for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 10:34:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBACIGMRY/3OXCkxdGgEBAQECAQEBAQgBAQEBg1FBkAuQXikBlx+GHAQCAoJARBQBAgEBAQEBAQFrKIUWAQQBViMFCws0EhQYDYovCLQfil8BAQEBBgIBJYs9hSCFGQWQWotnlByIYIZikX+BRDYhgQQjFggshzYiii4BAQE X-IPAS-Result: A0CtBACIGMRY/3OXCkxdGgEBAQECAQEBAQgBAQEBg1FBkAuQXikBlx+GHAQCAoJARBQBAgEBAQEBAQFrKIUWAQQBViMFCws0EhQYDYovCLQfil8BAQEBBgIBJYs9hSCFGQWQWotnlByIYIZikX+BRDYhgQQjFggshzYiii4BAQE X-IronPort-AV: E=Sophos;i="5.36,147,1486443600"; d="scan'208";a="295032572" Received: from 76-10-151-115.dsl.teksavvy.com (HELO pastel.home) ([76.10.151.115]) by smtp.teksavvy.com with ESMTP; 11 Mar 2017 10:33:44 -0500 Received: by pastel.home (Postfix, from userid 20848) id 836056184D; Sat, 11 Mar 2017 10:33:44 -0500 (EST) From: Stefan Monnier To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables Message-ID: References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> Date: Sat, 11 Mar 2017 10:33:44 -0500 In-Reply-To: <87mvcs8j7w.fsf@users.sourceforge.net> (npostavs's message of "Sat, 11 Mar 2017 00:40:03 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum , Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Actually, it's the indent-sexp on the whole object that takes time. > Possibly we could sacrifice some indentation correctness if the printed > representation is big. Actually, I think that trying to optimize this is bound to fail: we want *Help* to show up "instantly", so we're off by a factor of more than 100, which seems way out of reach (unless there's really an algorithmic problem in our code, admittedly). I think the better way out is to do less work. E.g. bound the total amount printed (and replace the rest with "..." that can be expanded on demand). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 10:34:16 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 15:34:16 +0000 Received: from localhost ([127.0.0.1]:51623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmj27-0001JW-Q7 for submit@debbugs.gnu.org; Sat, 11 Mar 2017 10:34:15 -0500 Received: from mail-it0-f43.google.com ([209.85.214.43]:36682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmj25-0001J6-8D for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 10:34:14 -0500 Received: by mail-it0-f43.google.com with SMTP id h10so10758319ith.1 for <25122@debbugs.gnu.org>; Sat, 11 Mar 2017 07:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=l9aOv3KQQrdm3yZNOivGFGSpjO6KSQU+1QXQP+8c0ps=; b=lUp33aOJVRV8CIsKo3s9qBCBvDHmP5oy7XTV3v6s4Exy0VyhGF0nR/osv7bEtoLGaZ QSTi8wGJcon8CLJfz3qTtS2JBwWazKuzJozC18XhEYlEmgILAuUP7RgxSyMoCfTQ1POd +wCbLZmgAb0NfFZq3E/eIHhsY74nBNRWYeugdQ7ZwqbGh4WUIRt1UfK4xiTJpDbrT3tz L2lE8QuprJbFGDnL8rsqVgimeZbdOq3thAYLxeXvl7Na0xg6K3TQp4LOSD6yMXbqFBrQ XaKuaSj1fVPSXAAITeWeEjsOGT21p0tUDalIeHH7FIqeZvhs/Mvbn+xzU7oRYi64mm+n xaGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=l9aOv3KQQrdm3yZNOivGFGSpjO6KSQU+1QXQP+8c0ps=; b=Qvhpk9cllz2Z5wI38m10vJzR0J+3yOkVPSiAYq5Iox0rKo/XV0ELMt6T8f/hP+UJ8t bzMuAA9FeBmZfyS88BxRnkOYgNQgM2W1hHI3WYzTvBdaZt0BKcxkDmVBcMoHJMbhMKMt sHDNto+YMZXBAq0zOFsVwDHB7XFsqffugGFWhU7y1XTFDhBuA45dJR0EQJl/hKUXNgm9 X5XZMTSmoh0K9vxvRblKMEYSdk1cAHHtYznBw72eaH8wD+fiBy4EHl7umTOhBBLJO8b7 GPc8M8ffPgf/NPZxdScTn3VcHSUQOHagEPcvq0bfWoxoES9opXS8g7SixT1i/y2/CMin YPog== X-Gm-Message-State: AFeK/H2ffTswcKRwOyry3qKYIFkRF7vrPkVHMyECV8OuskRiwFwBdFDmrRguAu/9w8HgGA== X-Received: by 10.36.219.10 with SMTP id c10mr3642359itg.1.1489246447482; Sat, 11 Mar 2017 07:34:07 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id s90sm5831680ioe.12.2017.03.11.07.34.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 Mar 2017 07:34:07 -0800 (PST) From: npostavs@users.sourceforge.net To: Stefan Monnier Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> Date: Sat, 11 Mar 2017 10:35:24 -0500 In-Reply-To: (Stefan Monnier's message of "Sat, 11 Mar 2017 10:21:53 -0500") Message-ID: <878tob9683.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: >> (cl-letf (((symbol-function 'pp) >> (lambda (object &optional stream) >> (let ((fn (lambda (ob &optional stream) >> (princ (pp-to-string ob) >> (or stream standard-output)) >> (terpri))) >> (print-circle t)) >> (if (consp object) >> (progn >> (insert "\n(") >> (mapc fn object) >> (cl-letf (((point) (1- (point)))) >> (insert ")"))) >> (funcall fn object stream)))))) > > Hmm... I wonder why this would be faster. In the past, the > implementation of `print-circle` had a poor complexity, but we fixed > that around Emacs-24, IIRC so it now uses a hash-table and should have > O(n) complexity, which means that pp shouldn't be slower than (mapc > #'pp). I think it's because when we indent-sexp only on individual entries, we don't parse as far back. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 14:27:09 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 19:27:09 +0000 Received: from localhost ([127.0.0.1]:51737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmmfV-00024Y-Ix for submit@debbugs.gnu.org; Sat, 11 Mar 2017 14:27:09 -0500 Received: from mail-wr0-f177.google.com ([209.85.128.177]:34436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmmfU-00024J-2o for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 14:27:08 -0500 Received: by mail-wr0-f177.google.com with SMTP id l37so82464755wrc.1 for <25122@debbugs.gnu.org>; Sat, 11 Mar 2017 11:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=U56e04zUdNOzPKogP6iAt7PgKfF9DHSywd+3uV+QNyU=; b=rM521k2YtAwBZHBpZY872FNYkvBpPDFdtK7NhlQnp67eonFXH4bowneDffM2waH3nz Sx71yDguAsvDUCBKp4V8yiVx010S2w0mMTe3XtHmldx1/W8mIu8yiboSuAP48xFSCOB3 Wdqu/BvkVLBd2khVCBMOCBb0wK0jsZHcMknlLvJRdiaIB5MpjbDt2S94U1AqRos7JgKA zNJitEH+aj0VntzlPauXkFMUjAiRj0NxbBiAjgR/K7Frf4nONBOaIEB1FV28aMz1nzUF fRThVgPXKCw2K8hwvKRFNg59hNHjidoi/cxrdlgz3K576YlckowTD5y9O478h/9wc+u8 Iw8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=U56e04zUdNOzPKogP6iAt7PgKfF9DHSywd+3uV+QNyU=; b=aZpbq40M7AwKADa05UBk0NLxUXyPxjLBenFdjHYG/DlrSBOFYHlytJfSr9lWDRkulV ehqE7fLdkuzs6TB1lhTv2T6AcR5kdATUSxAk3p/jjd5OYNTSRnxWP6UsyIM0onFdCES1 toH/PW/iEhg23CQo0ZSBhnO0yBLVWqsxULwRyXnoPrvr6MiaRYI6gy5luYw1XUHhSGot WepiV4Q91C4/uhBNfqGe5YgYGn6NszlpUyb8qwhQHx/c5RmClRLHD3hIpEacUA3qtiTv mHcyoz+BA32vW8mTHl2FwuBA3QOKmyxcUCIhnJCFAWntd0KdXHEmn+Kx+AP2T/KZPr2L BHag== X-Gm-Message-State: AMke39nwzdPyScPZKn3NCO0vXIe56FBEuq8pO0sD5neEGsGxoWLr/S+q1Wf4/5djF9NjkA== X-Received: by 10.223.175.238 with SMTP id y46mr20235408wrd.63.1489260422025; Sat, 11 Mar 2017 11:27:02 -0800 (PST) Received: from dell-14z ([37.167.6.162]) by smtp.gmail.com with ESMTPSA id 63sm4662128wmg.22.2017.03.11.11.27.00 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 11 Mar 2017 11:27:01 -0800 (PST) References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> User-agent: mu4e 0.9.19; emacs 25.1.2 From: Thierry Volpiatto To: Stefan Monnier Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables In-reply-to: Date: Sat, 11 Mar 2017 20:26:56 +0100 Message-ID: <87mvcrty0v.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: >> (cl-letf (((symbol-function 'pp) >> (lambda (object &optional stream) >> (let ((fn (lambda (ob &optional stream) >> (princ (pp-to-string ob) >> (or stream standard-output)) >> (terpri))) >> (print-circle t)) >> (if (consp object) >> (progn >> (insert "\n(") >> (mapc fn object) >> (cl-letf (((point) (1- (point)))) >> (insert ")"))) >> (funcall fn object stream)))))) > > Hmm... I wonder why this would be faster. However it is fast, it is anyway better than the actual situation were e.g C-h v load-history takes minutes in the best case to load the 1.8M help buffer. With this code it takes around 1s. > In the past, the implementation of `print-circle` had a poor > complexity, but we fixed that around Emacs-24, IIRC so it now uses a > hash-table and should have O(n) complexity, which means that pp > shouldn't be slower than (mapc #'pp). The code above run at the same speed with and without print-circle... -- Thierry From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 14:29:48 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 19:29:48 +0000 Received: from localhost ([127.0.0.1]:51742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmmi4-00028H-0g for submit@debbugs.gnu.org; Sat, 11 Mar 2017 14:29:48 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:36648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmmi2-000285-Nc for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 14:29:46 -0500 Received: by mail-wr0-f194.google.com with SMTP id l37so15345939wrc.3 for <25122@debbugs.gnu.org>; Sat, 11 Mar 2017 11:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=jpVN6PJ9FHi1sP/VQAJ9yWZsjBTwJTF/OZd6MNH6kYo=; b=dlI1raxm06tD1zre4qn+8ZDdcId/4ceeQHO4GVANHWc3TNkWZqZjJlxGy2VpwdqMpf OgeKhc4idUnGp5Xm0OECpttSicW8/i++9HvHeOCBhyOzjJ4IB6OxTsvhrLG/5RHa+ZsZ fFMTr71oXLWJmlj/uHfZOs4ke0GerNrZ6QQFqBXi9JUuWCiH0WTolW3AKhF+n19V8XqJ DqpGVndtvDrJkVLT9sx55EzqXJ4wt/n0AgieJguMVacCwCakjJ98E2E/lGA4yvxy3nbU 8DAZkSGGOW/aFrPzpcMipo7ACHcTkaC8OPbjj+T43X2BfV8Dl173g/f4Gor4iHlL0R94 BILA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=jpVN6PJ9FHi1sP/VQAJ9yWZsjBTwJTF/OZd6MNH6kYo=; b=pLLcnU5kAP+xQlW/QPGENaS0kbTkxZyzA8RWTgb0lWjZeEUxdrnnVa7hrL9PRPpqUn cZmGbHi71wC/bfqBKOe7Rr1BjB7AgCs1tujg4q4k02i+DI0FFo7pVsNp4WAPq4lyuFuY 2Tz+HrP+kfmPQUidJMTiGEyHygVOul/7m1SGWVDn9Y0wbQ6Zl5I3Hhss4CSWt5ylIuk0 wRCT8Ax45XfAQm8RP/b+J4V11oe5F2EJVmAJTmgoG8X6w2fkiVhhbIQn8IX39A9i+lwS E5IFpg5RlUauPofF2134Zd3EvAxBhno/lVujFDmCXB0rVDQbuP9RYOyKY5Wsw57TAxgE gl9Q== X-Gm-Message-State: AMke39k7Sf16QdS0/319lkjwZg4NsfW+Si2ywIhaFYQHD4O10keGmc6D+tcI5NbFoOvXEg== X-Received: by 10.223.129.4 with SMTP id 4mr24176110wrm.27.1489260581144; Sat, 11 Mar 2017 11:29:41 -0800 (PST) Received: from dell-14z ([37.167.6.162]) by smtp.gmail.com with ESMTPSA id s17sm18454525wrc.25.2017.03.11.11.29.39 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 11 Mar 2017 11:29:39 -0800 (PST) References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> User-agent: mu4e 0.9.19; emacs 25.1.2 From: Thierry Volpiatto To: Stefan Monnier Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables In-reply-to: Date: Sat, 11 Mar 2017 20:29:37 +0100 Message-ID: <87lgsbtxwe.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Stefan Monnier writes: > I think the better way out is to do less work. E.g. bound the total > amount printed (and replace the rest with "..." that can be expanded on > demand). The problem will be here again when you hit RET on "..." -- Thierry From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 14:34:21 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 19:34:21 +0000 Received: from localhost ([127.0.0.1]:51746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmmmT-0002HH-JH for submit@debbugs.gnu.org; Sat, 11 Mar 2017 14:34:21 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:34947) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmmmR-0002Gk-Nt for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 14:34:20 -0500 Received: by mail-wr0-f194.google.com with SMTP id u108so15418809wrb.2 for <25122@debbugs.gnu.org>; Sat, 11 Mar 2017 11:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=CKlCMt4c5r7Gvfk3TsoFaiuYD7R79Gw66NhNWDXn4z8=; b=T4bpaDSwKRAtYU87a3UoBYzuzFBNU38ci/3J3IQf3/50AJvvY3kkCscgCshhaSTZfJ 6mxm0l+1rcvO5gB9JTopRsvIStFR7H2bcRmWoCQFre3OgKroRHFtSL0AfdpTfec01edX 25nNHkF6B0UiVOi2wzcU/d6pdUEgLNlWQbt5SyqWXN9OwOthZftFPgtZ3ZarxpzUSmfI o6Cf0kwDN8S8ClPYgCsjkn8YyANHrDUp1NRIHlni4WZ/lIsMzTPBp+jLCEh6qLz+Z5Z3 6sidMaHxWNYHjQG8FSm4i4YobH7ULhEke96YTj1/7aUmGrZ6x5XVdrmGplIbs03mb7th ziOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=CKlCMt4c5r7Gvfk3TsoFaiuYD7R79Gw66NhNWDXn4z8=; b=TY/dacatrBcrnqIQNRz0AWvjNey6CHR0eH9AzZTS0v0DxwqfV9Zewy6UPpLnHHPwMi /UOyHCeP86CWJM3EuP1m4lmPEzQFyLaIi94efXcdPHi4g+l8PRBGOq8S6Jml6E493pHx gX74vfzQmWDMQitXJtUIhMS5QngJqbDKWmGlCh2mDLSdaZEb11/CeYANaA0Qk8ZKyOx2 9iswEkuVWeZkKfmGvaFPf1bg/GninuUAxX64iXOaxdBHFDjc1s6ioAKBODfuaYjUilOz tmceIYCJhjSE+oDbtZLXmSDg3Zj6LGTt1dIHYZ6W/yhX2Dx7nAykeNmqwRFCW5hlJy1I 1p1g== X-Gm-Message-State: AMke39nntQ15aziAEMtPEnIHOztF+d/mvCvv5oVUBIlFntKxB8P6S+IROHKcJBPnnqb1+g== X-Received: by 10.223.160.115 with SMTP id l48mr23268773wrl.24.1489260854220; Sat, 11 Mar 2017 11:34:14 -0800 (PST) Received: from dell-14z ([37.167.6.162]) by smtp.gmail.com with ESMTPSA id q75sm4683562wmd.27.2017.03.11.11.34.12 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 11 Mar 2017 11:34:13 -0800 (PST) References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> User-agent: mu4e 0.9.19; emacs 25.1.2 From: Thierry Volpiatto To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables In-reply-to: <87mvcs8j7w.fsf@users.sourceforge.net> Date: Sat, 11 Mar 2017 20:34:09 +0100 Message-ID: <87k27vtxou.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) npostavs@users.sourceforge.net writes: > I've been attempting an alternate approach which prettyprints the object > while scanning it instead of the current way of printing and then > reindenting. Without optimizing, it's about 3 times as fast as the > current pp (it's the pp-prin1 in the benchmarks below), though more than > 3 times slower than your mapc pp trick. On the other hand, it also > doesn't yet handle function-specific indentation or any compound > structure apart from lists, so I'm not sure if it will end up being much > faster. > > (benchmark 1 '(with-temp-buffer (pp-prin1 long-list (current-buffer)) nil)) "Elapsed time: 3.391232s (0.565806s in 11 GCs)" > (benchmark 1 '(progn (pp-to-string long-list) nil)) "Elapsed time: 9.988515s (0.148034s in 3 GCs)" > (benchmark 1 '(progn (with-output-to-string (mapc 'pp long-list)) nil)) "Elapsed time: 0.983493s (0.144424s in 3 GCs)" > (benchmark 1 '(progn (cl-prin1-to-string long-list) nil)) "Elapsed time: 0.511617s (0.152483s in 3 GCs)" > (benchmark 1 '(progn (prin1-to-string long-list) nil)) "Elapsed time: 0.029320s" Interesting, thanks to work on this. -- Thierry From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 16:57:56 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 21:57:56 +0000 Received: from localhost ([127.0.0.1]:51793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmp1Q-0000kt-7P for submit@debbugs.gnu.org; Sat, 11 Mar 2017 16:57:56 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:36378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmp1O-0000ke-1x for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 16:57:54 -0500 Received: by mail-it0-f67.google.com with SMTP id w185so2729326ita.3 for <25122@debbugs.gnu.org>; Sat, 11 Mar 2017 13:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=tKFY5zV+59n+FPwxaFOgKI1/iCId/1ArjQZ2KQH6M0U=; b=SyhvE5iEAIvXOPs3iRe+o4eNLsyg8hGIGuyWPK+tJnXGtNSbFvZVqA1Re12dZipfmX jgJZpGnrp4r0d6rG03L05HdFbAUmIuDbzDb4rv/YV6RvvgU6+4xYVtbQjuAxzlbx0L4K DRkJlSgHuFNsSeAP0lQSF8CH0k+kjTolH38wBMEdL7GUGPlmYSL8FIOmUa3IoiZ2CuNe W8SrtAD5poKodhCpnsnOU3syd6lT72UQYpVvJH83B2XDoH9MbxKniiyv1eWXxdJHLnsQ GDZb1GeZcpaEI6f1Z9MFJjoees7CFXX7f/Dd9Zamo6VbCoJjzasrupSRVraBBkQH0HFJ Qnjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=tKFY5zV+59n+FPwxaFOgKI1/iCId/1ArjQZ2KQH6M0U=; b=KaeI0B7aSFEjcBPCex0yi0q0YhOiWyom+v5JjgICESpqUvGC0o9SxRdrXcQ/rWG/Bk fvbGvRhqFupuUG/HL4H8ABLUurn7i/q7E182tXxr8yqLAw/6x67yi3VutKb2xYXxgkwt Y+xPZDqFiyNACvZF8zbN18zb0iAiTUxBVKGQyuQJNIpJ3e9kHslxf0Qbvz1HgCIvhv8A flvKUlS9yRwVoJFq9CzaPjdeE2RKtau359uvhufdnDDEOH06m7xWrHhVPANYX42w8YHX /tE8GBVylREVUhptUxH1ERN1v5rYYeBdaDG3S0pzCYWZ15Sx49N3W3Ltw6E24Wpo8g+8 XLCw== X-Gm-Message-State: AFeK/H2SUHRvNps70g4U6SObpZYQ87g8QzThO1+ifoOgCtxEpNxJDKqDtxVRuMAkCeyADg== X-Received: by 10.36.204.136 with SMTP id x130mr4971406itf.93.1489269468367; Sat, 11 Mar 2017 13:57:48 -0800 (PST) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id e4sm6201782ioe.7.2017.03.11.13.57.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 Mar 2017 13:57:47 -0800 (PST) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> Date: Sat, 11 Mar 2017 16:59:05 -0500 In-Reply-To: <87lgsbtxwe.fsf@gmail.com> (Thierry Volpiatto's message of "Sat, 11 Mar 2017 20:29:37 +0100") Message-ID: <871su38ogm.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Thierry Volpiatto writes: > Stefan Monnier writes: > >> I think the better way out is to do less work. E.g. bound the total >> amount printed (and replace the rest with "..." that can be expanded on >> demand). Yes, there's no method that will achieve "instant" speeds for load-history sized lists (well except for plain prin1, but that output is hardly readable). > The problem will be here again when you hit RET on "..." Perhaps we could run the printing in a thread and suspend it after printing X lines. Then hitting RET on "..." would just print another X lines. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 18:56:02 2017 Received: (at 25122) by debbugs.gnu.org; 11 Mar 2017 23:56:02 +0000 Received: from localhost ([127.0.0.1]:51841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmqri-0003YE-Gd for submit@debbugs.gnu.org; Sat, 11 Mar 2017 18:56:02 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:19513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmqrg-0003XQ-GC for 25122@debbugs.gnu.org; Sat, 11 Mar 2017 18:56:00 -0500 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2BNtrhw032191 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 Mar 2017 23:55:54 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v2BNtrfP001807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 Mar 2017 23:55:53 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v2BNtq1G007204; Sat, 11 Mar 2017 23:55:52 GMT MIME-Version: 1.0 Message-ID: <840af776-d1c9-4c81-a126-a6414a197a83@default> Date: Sat, 11 Mar 2017 15:55:50 -0800 (PST) From: Drew Adams To: npostavs@users.sourceforge.net, Thierry Volpiatto Subject: RE: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> In-Reply-To: <871su38ogm.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > >> I think the better way out is to do less work. E.g. bound the total > >> amount printed (and replace the rest with "..." that can be expanded o= n > >> demand). >=20 > Yes, there's no method that will achieve "instant" speeds for > load-history sized lists (well except for plain prin1, but that output > is hardly readable). >=20 > > The problem will be here again when you hit RET on "..." >=20 > Perhaps we could run the printing in a thread and suspend it after > printing X lines. Then hitting RET on "..." would just print another X > lines. (Caveat: I'm not really following this thread.) If you plan to do things like what I think you're suggesting, which will make a user hit several keys (e.g. RET on ... repeatedly) then please make that behavior _optional_. Give users the _possibility_ to just print the whole thing, without any other action (no prefix arg, no clicking ... etc.). I generally don't mind waiting, for example, and I don't want to have to hit ... and wait for a bit more - I want the whole thing the first time. And if/when you do show the value only partially, please make that _obvious_ to users. They should _immediately_ know that they are not seeing the full value. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 00:57:53 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 05:57:53 +0000 Received: from localhost ([127.0.0.1]:51934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmwVt-0007Qd-Ey for submit@debbugs.gnu.org; Sun, 12 Mar 2017 00:57:53 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:33960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmwVr-0007QQ-FV for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 00:57:51 -0500 Received: by mail-wr0-f194.google.com with SMTP id u48so16255009wrc.1 for <25122@debbugs.gnu.org>; Sat, 11 Mar 2017 21:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=4sU3DnYbbZCpoXgqQ/0ajqhLiJfuF4BcyXkS12D1QH4=; b=CNNeLyv2N9rrL+Vh7qsZWwjHXQLPWY5iELkjpRTFaB+188bEmJBp8003ypo+sb1IRw ur7Wk9kwwMtjppZtIMRLB9O05TTv4uVTICv/U1xapIbhYp9x2XCS5Xl+BfyZHMPlRsND RTLRDhqmQjHUsSMvu8cP+k5Tg70TrVUaTfBA5Ck7zknHAzbCZ6/rb0sJ5gEGqu+NFxgu VtD5Z1iDo1EZt2rXjXP/vw3PV11oY77uQc56nIPgajxO9zlUQPmcfeqSwha5DZq3pngu Lw/RynfB4t5PAwVZQ54yg46kGDMC4IVNjlcYipgUAz+AKMCaB/miNEfet1JilnUD5pJy Sx4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=4sU3DnYbbZCpoXgqQ/0ajqhLiJfuF4BcyXkS12D1QH4=; b=nm2gzPSkqCLS4o2wL+q1iiPCLRhkJAX+bvxfkIHT3rrwVraY3T8TIVWk4yVZSrNeSp qnK5889BCBqxCFEoYyYZHhuutI8BIbFhUrinMbdQ/Ewixget9FNjxBAvHAq4LLpf+3Yh JWNxkQ0ZY9N/zDI41pzI84J0N2r4UpikHrF4culHNaBKO4YvUisPg1vSKNEtUUeNtwln EldzcnGezuPTiCdtMgO5/VOaZ77XcSDIRI6CMYKHtw9lKcQQeuh+sU6iomRxMwtoRtFl qDJhmmrTmQz9Rk4FaufSmN1GrejhZakLpZ+7NJ0gqNPsUFX1TsmVmzCz5+fYZVXWD4aE LXEA== X-Gm-Message-State: AMke39k8grlXPZwFlkwg+Vw+iCO81tewmK66YMNH4R7jZfilaXse+2wbmwBNq3hBywCZRg== X-Received: by 10.223.170.200 with SMTP id i8mr25734668wrc.79.1489298265627; Sat, 11 Mar 2017 21:57:45 -0800 (PST) Received: from dell-14z ([37.165.155.81]) by smtp.gmail.com with ESMTPSA id f67sm6195056wmd.0.2017.03.11.21.57.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 11 Mar 2017 21:57:44 -0800 (PST) References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> User-agent: mu4e 0.9.19; emacs 24.5.1 From: Thierry Volpiatto To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables In-reply-to: <871su38ogm.fsf@users.sourceforge.net> Date: Sun, 12 Mar 2017 06:57:41 +0100 Message-ID: <87d1dnrq96.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) npostavs@users.sourceforge.net writes: > Perhaps we could run the printing in a thread This is a good idea. > and suspend it after printing X lines. Instead just print something like "Computing foo value ..." and let finish the thread, letting user reading and moving cursor in docstring while it finishes, once done save-excursion and send message "Computing foo value done". > Then hitting RET on "..." would just print another X lines. I think like Drew that this would be annoying. That said, what's the reason of choosing the slower approach to compute value (in a thread or not) instead of using the approach described in the advice I sent here which takes 1s to compute load-history instead of 3mn ? (I use this advice since one year now without any problems). -- Thierry From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 10:07:47 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 14:07:47 +0000 Received: from localhost ([127.0.0.1]:52732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn49y-0004J5-Si for submit@debbugs.gnu.org; Sun, 12 Mar 2017 10:07:47 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:7823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn49x-0004Is-Fk for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 10:07:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BACQCZVcVY/9TkSC1cGgEBAQECAQEBAQgBAQEBg1FBhDyFV4V4kFwpAZcfhhwEAgKCQEQUAQIBAQEBAQEBayiFFgEEAVYjBQsLNBIUGA0kigsIs3yKXQEBAQEGAiaLPYo5AQScQZQciGCGYpNDNiGBBCMWCCyFGB2BfySKIwEBAQ X-IPAS-Result: A0BACQCZVcVY/9TkSC1cGgEBAQECAQEBAQgBAQEBg1FBhDyFV4V4kFwpAZcfhhwEAgKCQEQUAQIBAQEBAQEBayiFFgEEAVYjBQsLNBIUGA0kigsIs3yKXQEBAQEGAiaLPYo5AQScQZQciGCGYpNDNiGBBCMWCCyFGB2BfySKIwEBAQ X-IronPort-AV: E=Sophos;i="5.36,152,1486443600"; d="scan'208";a="295082940" Received: from 45-72-228-212.cpe.teksavvy.com (HELO pastel.home) ([45.72.228.212]) by smtp.teksavvy.com with ESMTP; 12 Mar 2017 10:07:39 -0400 Received: by pastel.home (Postfix, from userid 20848) id 949C06187C; Sun, 12 Mar 2017 10:07:39 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables Message-ID: References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> Date: Sun, 12 Mar 2017 10:07:39 -0400 In-Reply-To: <87d1dnrq96.fsf@gmail.com> (Thierry Volpiatto's message of "Sun, 12 Mar 2017 06:57:41 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > That said, what's the reason of choosing the slower approach to compute > value (in a thread or not) instead of using the approach described in > the advice I sent here which takes 1s to compute load-history instead of > 3mn ? (I use this advice since one year now without any problems). Yes, we should definitely do that. I'm still not sure why it's so much faster: it indicates we have a performance bug in pp.el and all it take is to fix it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 10:14:11 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 14:14:11 +0000 Received: from localhost ([127.0.0.1]:52737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn4GB-0004Rs-Il for submit@debbugs.gnu.org; Sun, 12 Mar 2017 10:14:11 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:34260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn4G9-0004Re-HX for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 10:14:09 -0400 Received: by mail-it0-f65.google.com with SMTP id r141so3726640ita.1 for <25122@debbugs.gnu.org>; Sun, 12 Mar 2017 07:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=xgoXNydUtUDM2TayMQIfCGeVsCvc/CU9OpEMFeNKjos=; b=NgT5LgjQ1l6k1qCnZfxFZPRMZNjFZmQc4Nn5jJDMfKGIuPLcRQUzZoaTVGc+YIenS2 deJBoQT0cqUZ7MoN9AFo1tWkv3J2+38EY5RZ1QCur1vPQgguP0Hti5JkHp9C+ahm529/ Ug/92Znq4yWRerMHgMe3pW+URaaOjhvaS3QqOzFgMkt/oPxrN6nkhMicsKTdm063xAVy 4/lbj2SwIOKZ6++3i4lZKJdPYEgfMlZa3jHostxopfi8Jq59IumY1ntckYxMxxSQNC+k ADwReiZ7KW+m7WPBWLlIdUCebKyHauvoCsp8I3iUMyLxpkiLQ5IHepdHNj7DMe6ne2pD kn4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=xgoXNydUtUDM2TayMQIfCGeVsCvc/CU9OpEMFeNKjos=; b=Jm0DpIC1x+YxbYkppUpC1fzDVYaHy3gOqSCT9FnJMHnPP7/T6KG9vP1BjHq30TzF9a Ph9+qTSIuklL1GM3piMfI3hKNi9oqpazSVBfXN0DDyzh+rS2q+tAu6OkLGZT50fIGQqs Oi2OK4ZyvuC8jPQhdmDWyN5BQnI2Vb5KiPOlvstEKeuOOahEab4S1gA+GaxEGOyejskO g6JpU4B1S6eFfREeofDWK7yZVV7A4VNMZfQRKvLbdd/a0GOCk5E678InGjbCWmSqStC3 4uHJZs4zlpGoX/YDcPs/mQ91fZDhlt6HsjM5zngbSRlB3PublquvVFYen0QDYd4OTjnP IZVg== X-Gm-Message-State: AFeK/H0ELY0mCJKGgGgdDbr1hx6S2WV1SK9G6jYcXe8kxNphI03DYYKfRsdT67Re+ZE5uQ== X-Received: by 10.36.54.149 with SMTP id l143mr6563665itl.38.1489328044067; Sun, 12 Mar 2017 07:14:04 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id v197sm2747541ita.2.2017.03.12.07.14.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 Mar 2017 07:14:03 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> Date: Sun, 12 Mar 2017 10:15:21 -0400 In-Reply-To: <87d1dnrq96.fsf@gmail.com> (Thierry Volpiatto's message of "Sun, 12 Mar 2017 06:57:41 +0100") Message-ID: <87wpbu7f9i.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Thierry Volpiatto writes: > npostavs@users.sourceforge.net writes: > >> and suspend it after printing X lines. > > Instead just print something like "Computing foo value ..." and let finish > the thread, letting user reading and moving cursor in docstring while it > finishes, once done save-excursion and send message "Computing foo value > done". Threads aren't truly parallel. The user can't do anything while the thread is running. > >> Then hitting RET on "..." would just print another X lines. > > I think like Drew that this would be annoying. I wonder if we could just hook this into scrolling somehow? So the lines would only be printed when you scroll to look at them. > > That said, what's the reason of choosing the slower approach to compute > value (in a thread or not) instead of using the approach described in > the advice I sent here which takes 1s to compute load-history instead of > 3mn ? (I use this advice since one year now without any problems). As mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21717#8, it breaks circularity. Try describing this variable: (defvar circular-list (let ((l (number-sequence 1 100))) (setcdr (last l) l) l) "A circular list that has problems with (mapc 'pp val).") We could probably achieve something similar without breaking circular printing by not calling indent-sexp on the full list, but 1s is longer than "instant" anyway (which is about 50ms or less) which is why I'm exploring other options. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 10:59:16 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 14:59:16 +0000 Received: from localhost ([127.0.0.1]:52756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn4xn-0005Vx-Vt for submit@debbugs.gnu.org; Sun, 12 Mar 2017 10:59:16 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:47941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn4xm-0005Vk-Ns for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 10:59:15 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2CEx66Y027479 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 12 Mar 2017 14:59:07 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v2CEx6pE009790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 12 Mar 2017 14:59:06 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v2CEx3Dq018419; Sun, 12 Mar 2017 14:59:04 GMT MIME-Version: 1.0 Message-ID: <4287f60a-fa04-4fcd-8b61-a319cd5b2abe@default> Date: Sun, 12 Mar 2017 07:59:03 -0700 (PDT) From: Drew Adams To: npostavs@users.sourceforge.net, Thierry Volpiatto Subject: RE: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> In-Reply-To: <87wpbu7f9i.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) > >> Then hitting RET on "..." would just print another X lines. > > > > I think like Drew that this would be annoying. >=20 > I wonder if we could just hook this into scrolling somehow? So the > lines would only be printed when you scroll to look at them. I still would not like that behavior, so would would want to opt out, personally. If it take a minute to display *Help* I can at least do something different (outside Emacs) during that time. When I'm scrolling I'm likely examining the value as it scrolls, and I don't want to wait (scrolling in chunks separated by delays). E.g., I do `C-h v bookmark-alist' or `load-history' with a large list. I know that it will not display immediately, so I don't grumble about that fact. I'm free not to sit and stare at the screen waiting for it to return. What you describe just chops up the wait into scrolled chunks. > > That said, what's the reason of choosing the slower approach to compute > > value (in a thread or not) instead of using the approach described in > > the advice I sent here which takes 1s to compute load-history instead o= f > > 3mn ? (I use this advice since one year now without any problems). >=20 > As mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D21717#8, > it breaks circularity. Try describing this variable: >=20 > (defvar circular-list > (let ((l (number-sequence 1 100))) (setcdr (last l) l) l) "") >=20 > We could probably achieve something similar without breaking circular > printing by not calling indent-sexp on the full list, but 1s is longer > than "instant" anyway (which is about 50ms or less) which is why I'm > exploring other options. 1 sec is not a problem, IMO. 0.7 sec is a typical Emacs `sit-for' value, i.e., something that, yes, allows time to notice the change/wait, but it is not so long that it becomes annoying. (It would be annoying if it happened for all or most *Help* displays, but printing large values is the exception.) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 12:06:33 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 16:06:33 +0000 Received: from localhost ([127.0.0.1]:52791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn60v-0007A5-Do for submit@debbugs.gnu.org; Sun, 12 Mar 2017 12:06:33 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:35006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn60t-00079t-Ex for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 12:06:31 -0400 Received: by mail-it0-f49.google.com with SMTP id m27so17933862iti.0 for <25122@debbugs.gnu.org>; Sun, 12 Mar 2017 09:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=e8Ilt2LeU2fwTMN/Y/fTbCx9cutrNRzYLEtD5CCRjT0=; b=V/NIWL2OTPZlgVRzMMzSSLBfLPtfjL8HmvUH8aidvbVgX0DkeWsOW0vRU/RTRFna0E drg41Qot94irlIKt/kx1Jqgjn5EM77a293YKjDg6DWbccl0DqD1IVc33mbb9NW3rgKqq 9h/cUVwNie6XWo7YfAe4NFcctNXeHs+HOyIKGQXLPqgUNQQVH2eu2pnHgmy5jASovRoU e51XDQrSGwCS5zi3KD6EG0uGjnInbqKG/NFdzmxROiYqucM0O0ZadCcUP30aekIjlki0 vmt15q0DClP78eHgV3JIgNHUUGTv5wWd3crDtUWhRp2DlVCcqE7rru3io+GCduCmmvOh tFJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=e8Ilt2LeU2fwTMN/Y/fTbCx9cutrNRzYLEtD5CCRjT0=; b=LWd0489Hv20zzRrDVAymVGvBMEHyKXz/ypowcKZpQ7k7Wi0YcNfmJK4/SLLQ7TwHED Z1uV/ia+N6PIHBw2ZHObV7As1QeLFyHtNx038Sn866/U2IXtLd5GP3Kv+4PQ/RX/OwIn n9j3sTU62dyT8sNl2BmPhWaMQRJrcCqe9ywxTLQ8Iiz8MH68MZLF43UY9DRpe2MZ10gs w+X3Fus7iT2uXoFpHlcUyMapwHFdDQP01WYNbkZZlHie6mykA1lkaWVFcE3RCgLvq/WE m5lYCP2VNT5s6acnTyQGLlLNgl/3qQdd4bBYUn60cCmvAJZ4/P+kibIiGFsLqWD0+nGB Abkw== X-Gm-Message-State: AFeK/H02siNuLILimX0phVMm35J5qGiNx9PqfC+egtpQQtqqtYZwAweIT008FlK003Q8iA== X-Received: by 10.36.10.13 with SMTP id 13mr7310121itw.110.1489334785969; Sun, 12 Mar 2017 09:06:25 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id x100sm2524096ita.12.2017.03.12.09.06.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 Mar 2017 09:06:25 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87k27vtxou.fsf@gmail.com> Date: Sun, 12 Mar 2017 12:07:43 -0400 In-Reply-To: <87k27vtxou.fsf@gmail.com> (Thierry Volpiatto's message of "Sat, 11 Mar 2017 20:34:09 +0100") Message-ID: <87tw6y7a28.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --=-=-= Content-Type: text/plain Thierry Volpiatto writes: > npostavs@users.sourceforge.net writes: > >> I've been attempting an alternate approach which prettyprints the object >> while scanning it instead of the current way of printing and then >> reindenting. Without optimizing, it's about 3 times as fast as the >> current pp (it's the pp-prin1 in the benchmarks below), though more than >> 3 times slower than your mapc pp trick. On the other hand, it also >> doesn't yet handle function-specific indentation or any compound >> structure apart from lists, so I'm not sure if it will end up being much >> faster. >> >> (benchmark 1 '(with-temp-buffer (pp-prin1 long-list (current-buffer)) nil)) "Elapsed time: 3.391232s (0.565806s in 11 GCs)" >> (benchmark 1 '(progn (pp-to-string long-list) nil)) "Elapsed time: 9.988515s (0.148034s in 3 GCs)" >> (benchmark 1 '(progn (with-output-to-string (mapc 'pp long-list)) nil)) "Elapsed time: 0.983493s (0.144424s in 3 GCs)" >> (benchmark 1 '(progn (cl-prin1-to-string long-list) nil)) "Elapsed time: 0.511617s (0.152483s in 3 GCs)" >> (benchmark 1 '(progn (prin1-to-string long-list) nil)) "Elapsed time: 0.029320s" > > Interesting, thanks to work on this. With a couple of minor optimizations it's down to about 1.8s. The first is to reuse the tempbuffer instead of letting cl-prin1-to-string make a new one each time. Second is to add (eval-when-compile (cl-proclaim '(optimize (speed 3) (safety 0)))) This also stops these warnings (I guess they're caused by the "safety" code?): ../../emacs-master/lisp/emacs-lisp/pp.el:159:19:Warning: value returned from (aref state 6) is unused ../../emacs-master/lisp/emacs-lisp/pp.el:204:24:Warning: value returned from (aref state 10) is unused New times: (benchmark 1 '(with-temp-buffer (pp-prin1 long-list (current-buffer)) nil)) "Elapsed time: 1.800146s (0.231706s in 6 GCs)" (benchmark 1 '(progn (pp-to-string long-list) nil)) "Elapsed time: 9.950225s (0.154100s in 4 GCs)" (benchmark 1 '(progn (with-output-to-string (mapc 'pp long-list)) nil)) "Elapsed time: 0.980923s (0.149787s in 4 GCs)" I foolishly neglected to write down what exactly long-list was before, starting from emacs -Q this seems to approximate it though: (progn (require 'pp) (require 'dabbrev) (require 'edebug) (require 'cc-mode) (require 'vc) (setq long-list load-history) (length long-list)) ;=> 142 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v2-0001-New-pretty-printer-Bug-25122.patch Content-Description: patch >From e4b1a2ef3b4b11466e81d639a09ff671318e0968 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 11 Mar 2017 00:09:36 -0500 Subject: [PATCH v2] New pretty printer (Bug#25122) * lisp/emacs-lisp/pp.el (pp-state): New struct. (pp--scan): New function, measures length of sublists (actually "logical blocks" to allow for more customizable grouping than just by lists). Calls pp--print when scanned tokens are too wide to fit on a single line. (pp--print): New function, prints tokens horizontally or vertically depending on whether the sublist can fit within the line. (pp-prin1): New function, entry point for pp--scan and pp-print. (pp-print-object): New generic function. (pp-print-object) : New method, prettyprinter for lists. --- lisp/emacs-lisp/pp.el | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index 7ef46a48bd..8c2ed24ffd 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -24,6 +24,9 @@ ;;; Code: +(eval-when-compile (require 'cl-lib)) +(require 'ring) + (defvar font-lock-verbose) (defgroup pp nil @@ -121,6 +124,159 @@ pp-display-expression (setq buffer-read-only nil) (set (make-local-variable 'font-lock-verbose) nil))))) +(eval-when-compile + ;; FIXME: should we try to restore original settings? (how?) + (cl-proclaim '(optimize (speed 3) (safety 0)))) + +(cl-defstruct (pp-state (:constructor + make-pp-state + (stream + tempbuffer + right-margin + &aux + (left-margin 0) + (indent '(0)) + (scan-depth 0) + (print-depth 0) + (print-width 0) + (scan-width 0) + (block-mode (list nil)) + (fifo (make-ring 30))))) + stream + tempbuffer + right-margin ; how far we may go. + left-margin ; how far printer has gone + print-width ; total width of tokens printed so far. + indent ; left-margin, stack per depth. + scan-width ; total width of tokens scanned so far. + scan-depth + print-depth + block-widths + block-mode ; `:vertical', `:horizontal', nil (undecided); stack per depth. + fifo + ) + +(defun pp--print (state) + (cl-symbol-macrolet ((stream (pp-state-stream state)) + (depth (pp-state-print-depth state)) + (scan-depth (pp-state-scan-depth state)) + (fifo (pp-state-fifo state)) + (left-margin (pp-state-left-margin state)) + (width (pp-state-print-width state)) + (indent (pp-state-indent state)) + (right-margin (pp-state-right-margin state)) + (block-mode (pp-state-block-mode state))) + (catch 'rescan + (while (not (ring-empty-p fifo)) + (pcase (ring-remove fifo) + ((and `(,len . :open-block) token) + (if (<= len 0) + ;; Not ready to print this yet! + (progn (ring-insert-at-beginning fifo token) + (throw 'rescan nil)) + (cl-incf depth) + (push left-margin indent) + (push (if (> (+ left-margin len) right-margin) + :vertical :horizontal) + block-mode))) + (:close-block (cl-decf depth) (pop indent) (pop block-mode)) + (:blank + (pcase (car block-mode) + (:vertical + (terpri stream) + (princ (make-string (car indent) ?\s) stream) + (setf left-margin (car indent))) + ((or :horizontal 'nil) + (write-char ?\s stream) + (cl-incf left-margin)) + (_ (error "oops"))) + (cl-incf width)) + (:eof nil) + ((and (pred characterp) char) + (write-char char stream) + (cl-incf left-margin (char-width char)) + (cl-incf width (char-width char))) + (string + (princ string stream) + (cl-incf left-margin (string-width string)) + (cl-incf width (string-width string)))))))) + +(defun pp--scan (token state) + (cl-symbol-macrolet ((stream (pp-state-stream state)) + (depth (pp-state-scan-depth state)) + (print-depth (pp-state-print-depth state)) + (fifo (pp-state-fifo state)) + (width (pp-state-scan-width state)) + (right-margin (pp-state-right-margin state)) + (block-widths (pp-state-block-widths state))) + (cl-flet ((scanlen (len) (cl-incf width len))) + (cl-assert (> (ring-size fifo) (ring-length fifo))) + (ring-insert fifo token) + (pcase token + (:open-block + (cl-incf depth) + (let ((block-token (cons (- width) (ring-remove fifo 0)))) + (push block-token block-widths) + (ring-insert fifo block-token))) + (:close-block + (cl-incf (caar block-widths) width) + (when (> (caar block-widths) right-margin) + (pp--print state)) + (cl-decf depth) + (pop block-widths)) + (:blank (scanlen 1)) + (:eof (pp--print state)) + ((pred characterp) (scanlen (char-width token))) + (_ (scanlen (string-width token))))) + (when block-widths + (when (> (+ (caar block-widths) width) right-margin) + (dolist (block-width block-widths) + (setf (car block-width) (+ right-margin 1)))) + (when (> (caar block-widths) right-margin) + (pp--print state))))) + +(defvar cl-print-readably) ; cl-print.el + +(defun pp-prin1 (object &optional stream right-margin) + (unless right-margin + (setq right-margin fill-column)) + (with-temp-buffer + (let ((cl-print-readably nil) + (state (make-pp-state (or stream standard-output) (current-buffer) + right-margin))) + (pp--scan :open-block state) + (prog1 (pp-print-object object state) + (pp--scan :close-block state) + (pp--scan :eof state))))) + + +(cl-defgeneric pp-print-object (object state) + ;; Fallback to standard `cl-print-object'. + (pp--scan (with-current-buffer (pp-state-tempbuffer state) + (cl-prin1 object (current-buffer)) + (prog1 (buffer-string) + (erase-buffer))) + state) + object) + +(cl-defmethod pp-print-object ((list cons) state) + (pcase list + (`(,head . ,tail) + (pp--scan "(" state) + (pp--scan :open-block state) + (pp-print-object head state) + (while (consp tail) + (pp--scan :blank state) + (pp-print-object (pop tail) state)) + (when tail + (pp--scan :blank state) + (pp--scan ?\. state) + (pp--scan :blank state) + (pp-print-object tail state)) + (pp--scan :close-block state) + (pp--scan ")" state))) + list) + ;;;###autoload (defun pp-eval-expression (expression) "Evaluate EXPRESSION and pretty-print its value. -- 2.11.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 12:29:25 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 16:29:25 +0000 Received: from localhost ([127.0.0.1]:52799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn6N3-0007fA-K4 for submit@debbugs.gnu.org; Sun, 12 Mar 2017 12:29:25 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:63115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn6N1-0007ex-IJ for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 12:29:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFBAA0dsVY/9TkSC1cGgEBAQECAQEBAQgBAQEBg1FBIIEKgxKLT5BcKQGVEYIOKoVyBAICgkBCFgECAQEBAQEBAWsohRYBBAFWIwULCzQSFBgNUoldCA6zaIpcAQEBAQEFAgEgBYs9gxeCCYUZBZxBhnaWBoZik0MmDCWBBCMWCCxBhnMkNQGJbQEBAQ X-IPAS-Result: A0DFBAA0dsVY/9TkSC1cGgEBAQECAQEBAQgBAQEBg1FBIIEKgxKLT5BcKQGVEYIOKoVyBAICgkBCFgECAQEBAQEBAWsohRYBBAFWIwULCzQSFBgNUoldCA6zaIpcAQEBAQEFAgEgBYs9gxeCCYUZBZxBhnaWBoZik0MmDCWBBCMWCCxBhnMkNQGJbQEBAQ X-IronPort-AV: E=Sophos;i="5.36,152,1486443600"; d="scan'208";a="295089021" Received: from 45-72-228-212.cpe.teksavvy.com (HELO pastel.home) ([45.72.228.212]) by smtp.teksavvy.com with ESMTP; 12 Mar 2017 12:29:17 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9672461876; Sun, 12 Mar 2017 12:29:16 -0400 (EDT) From: Stefan Monnier To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables Message-ID: References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> Date: Sun, 12 Mar 2017 12:29:16 -0400 In-Reply-To: <87wpbu7f9i.fsf@users.sourceforge.net> (npostavs's message of "Sun, 12 Mar 2017 10:15:21 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Boruch Baum , Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Threads aren't truly parallel. The user can't do anything while the > thread is running. I think the idea is to build the printout while the user is reading the docstring (for example). The loop that prints would have regular `yield` calls so that as soon as not to block other operations. > I wonder if we could just hook this into scrolling somehow? We definitely could (at least, there's no fundamental reason why we can't insert the text from a jit-lock thingy, although modifying the buffer text from jit-lock might trigger some latent bugs). > As mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21717#8, > it breaks circularity. Try describing this variable: > (defvar circular-list > (let ((l (number-sequence 1 100))) > (setcdr (last l) l) > l) > "A circular list that has problems with (mapc 'pp val).") That's why I think the (mapc #'pp) trick is an interesting observation (it points to a performance bug that should be easy to fix) but is not a solution in itself. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 12:31:38 2017 Received: (at 25122) by debbugs.gnu.org; 12 Mar 2017 16:31:38 +0000 Received: from localhost ([127.0.0.1]:52803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn6PC-0007jV-1K for submit@debbugs.gnu.org; Sun, 12 Mar 2017 12:31:38 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:36576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cn6PA-0007jI-Cc for 25122@debbugs.gnu.org; Sun, 12 Mar 2017 12:31:36 -0400 Received: by mail-io0-f193.google.com with SMTP id 68so11299212ioh.3 for <25122@debbugs.gnu.org>; Sun, 12 Mar 2017 09:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=jxkQqfgW2s1qkVZf7U+Oye4rnuvtA5i7B1vTTOx/ok8=; b=a9m23JAbtt0CpfjFjNi7ZqgCF9jvyx94IypkhBhETTJupwZgqc/0p7k5b8Aa/l4tt4 m2kiO6pR6pouJSXdiVGbtwbGCjAsoryGq7hlWWfpfBKoYeCsl9TARg3aA7oLKIAnCmCB PDkBYAi58yxLgNBPEeaVqQQy1McOEriR/EqSO1yrVUaHkOmqE2aSWqXGM/hhOjYaSVd0 tGMaLObThePxkOVr0QPO4Bkts10kMJ+6An8XRofpImnIQSew3f43wwiHNiSCheOWtdzC wju+fcJBA8A7LOHXulNzi2unLj9WPezpFC6LgEfxnTIBV5uIGrqBaa08q5aupKWDGMQ7 xrCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=jxkQqfgW2s1qkVZf7U+Oye4rnuvtA5i7B1vTTOx/ok8=; b=Gi627ZvstZXAiEpbip0u5N6NfaaY1YifOKlGqwJyuQTmq6AlgDy2A6kSeE+xht9qLp fg/CkNKdHjjUBrGNUjYG8n5zJs08SWdIBaSThW7f+mm5lqgIPvE4hEVShVFsfNVNbeOr cmmwwlhNP+53LgQyuRcx8iLU3cqUEP7phegNRFi7PpCjSuuJU9PkIIoSSXc3/Q/If6Vh nfIe9S2pmc90Mdt/BbjR9VImpaYvri+1ZUBDWmGqUfZeMIbBuf0TornWvJWT/hiwPJk2 +itxaeDpWYCCLFEpbk/sq+T4mvcHQ9USywnsymwW7ukQP32uVGJbk9SpixD6m1nil+Ts JBFA== X-Gm-Message-State: AMke39nyG/cNZy7aDe+99aZhB4JgZa8OPVgAzGFMlF8UAB3h/e+G28G11/mqYL28Gev0qg== X-Received: by 10.107.28.73 with SMTP id c70mr26008440ioc.198.1489336290773; Sun, 12 Mar 2017 09:31:30 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id e20sm2727664itc.3.2017.03.12.09.31.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 Mar 2017 09:31:30 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> Date: Sun, 12 Mar 2017 12:32:48 -0400 In-Reply-To: <87wpbu7f9i.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Sun, 12 Mar 2017 10:15:21 -0400") Message-ID: <87r32278wf.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.8 (/) > We could probably achieve something similar without breaking circular > printing by not calling indent-sexp on the full list The following patch is almost as fast as the mapc 'pp trick, but doesn't get stuck on circular lists. The indentation is a bit off: sublists after the first one incorrectly start in column 0. Also, this doesn't really solve the performance problem, it just makes it much less likely to occur, e.g., (pp (list load-history)) is still slow. --- i/lisp/emacs-lisp/pp.el +++ w/lisp/emacs-lisp/pp.el @@ -76,9 +76,15 @@ pp-buffer (progn (skip-chars-forward " \t\n") (point))) (insert ?\n)) (t (goto-char (point-max))))) (goto-char (point-min)) - (indent-sexp)) + (condition-case () (down-list) + (scan-error nil)) + (while (and (not (eobp)) + (condition-case () (progn (indent-sexp) + (forward-sexp) + t) + (scan-error nil))))) ;;;###autoload (defun pp (object &optional stream) "Output the pretty-printed representation of OBJECT, any Lisp object. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 13 00:46:30 2017 Received: (at 25122) by debbugs.gnu.org; 13 Mar 2017 04:46:30 +0000 Received: from localhost ([127.0.0.1]:53129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cnHsM-0001n0-6V for submit@debbugs.gnu.org; Mon, 13 Mar 2017 00:46:30 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:37445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cnHsJ-0001mg-M6; Mon, 13 Mar 2017 00:46:28 -0400 Received: by mail-it0-f43.google.com with SMTP id g138so25236000itb.0; Sun, 12 Mar 2017 21:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=+HVfNan0vzQbhsFpVI3DS0tkNCwHH97eXeXRsVbcBjo=; b=UMY3uVeUNDTxRdi96i2yfH4q5h/D3IQ484RDHqw1DV4ksKrxqvreNjtECcGYj142Np nGyXxMm2Jpw0KIlkJzYFEi+zIfPdIy2HR6HPfigAE10BUKhx8I1ArHbj4an+pnNTOlXg jearI/37Rsa/alLW/FbqUgipgqTkpfjMIgml7i9fm1XGyCsdIVY6Z0MSIs+Oc8PAS3+w 7eigdt7alR4kw7zV9ik7K87Co9lzqQlQbtC99Mh0fpQ8DgK2r16EFy4RmtwrlqXn/Mfp 9QqBucgg+WQuIL3jXnm5mkI/QPs/Yj0u6Wj9jAPSQdp3YALlJ4mkMoGEt53OK4MrXrUy 0zvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=+HVfNan0vzQbhsFpVI3DS0tkNCwHH97eXeXRsVbcBjo=; b=ZUfrUTyAjt21TtuMJH3LlolP5XMwjccEf5Wjkg/PABbuNmnf3nZr3keKO5qpdSEJKX 87MPQxxvE9F5sP6kp7Rv8ChSO+BVK+KaMUoiaMgyRcPxLj+v8/qKaZ2w2u1Mk4zHNogF CC1lWzG0WF9mo75/rmyfhrr0UuFyxUy7KKnBB88P6zOT0dJT9ljx0sTQm2wI4BkLqrjC uPb+Tmnlw4jw5eVVuaNywfHXQr8g9dfesJv6iV5Os20MFJqMGwIATDOK5JMSKJ3/yzQd ErQYYU1Rvr4ejq15x2IPW4pOJUWQz2Gno36kGAM6OJ/68iI5klsmTlUQBaO6d8/wzOtn i8hg== X-Gm-Message-State: AFeK/H3d87TE8551ojJet+4S4hGDfh0WO1KWmsvoXP3CiUAjC4Z3ZaZuoou3OoGw/f+dwA== X-Received: by 10.36.153.197 with SMTP id a188mr9297425ite.5.1489380382055; Sun, 12 Mar 2017 21:46:22 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id 62sm3744204itl.1.2017.03.12.21.46.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 Mar 2017 21:46:21 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> Date: Mon, 13 Mar 2017 00:47:38 -0400 In-Reply-To: <87r32278wf.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Sun, 12 Mar 2017 12:32:48 -0400") Message-ID: <87lgs97pg5.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --=-=-= Content-Type: text/plain tags 25122 patch quit npostavs@users.sourceforge.net writes: > Also, this doesn't really solve the performance problem, it just makes > it much less likely to occur, e.g., (pp (list load-history)) is still > slow. Okay, I think I found the real fix now: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Don-t-reparse-the-sexp-in-indent-sexp-Bug-25122.patch Content-Description: patch >From 5188d6e366426d83934505296b585744f50e24a5 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sun, 12 Mar 2017 23:59:19 -0400 Subject: [PATCH] Don't reparse the sexp in indent-sexp (Bug#25122) * lisp/emacs-lisp/lisp-mode.el (calculate-lisp-indent): Let PARSE-START be a parse state that can be reused. (indent-sexp): Pass the running parse state to calculate-lisp-indent instead of the sexp beginning position. --- lisp/emacs-lisp/lisp-mode.el | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index eb07c18b03..8d4abc24e8 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -781,6 +781,10 @@ calculate-lisp-indent If the value is nil, that means don't change the indentation because the line starts inside a string. +PARSE-START may be a buffer position to start parsing from, or a +parse state as returned by calling `parse-partial-sexp' up to the +beginning of the current line. + The value can also be a list of the form (COLUMN CONTAINING-SEXP-START). This means that following lines at the same level of indentation should not necessarily be indented the same as this line. @@ -794,12 +798,14 @@ calculate-lisp-indent (desired-indent nil) (retry t) calculate-lisp-indent-last-sexp containing-sexp) - (if parse-start - (goto-char parse-start) - (beginning-of-defun)) - ;; Find outermost containing sexp - (while (< (point) indent-point) - (setq state (parse-partial-sexp (point) indent-point 0))) + (cond ((or (markerp parse-start) (integerp parse-start)) + (goto-char parse-start)) + ((null parse-start) (beginning-of-defun)) + (t (setq state parse-start))) + (unless state + ;; Find outermost containing sexp + (while (< (point) indent-point) + (setq state (parse-partial-sexp (point) indent-point 0)))) ;; Find innermost containing sexp (while (and retry state @@ -1070,11 +1076,6 @@ indent-sexp ENDPOS is encountered." (interactive) (let* ((indent-stack (list nil)) - ;; If ENDPOS is non-nil, use beginning of defun as STARTING-POINT. - ;; If ENDPOS is nil, it is safe not to scan before point - ;; since every line we indent is more deeply nested than point is. - (starting-point (save-excursion (if endpos (beginning-of-defun)) - (point))) ;; Use `syntax-ppss' to get initial state so we don't get ;; confused by starting inside a string. We don't use ;; `syntax-ppss' in the loop, because this is measurably @@ -1132,8 +1133,12 @@ indent-sexp (unless (or (eolp) (eq (char-syntax (char-after)) ?<)) (let ((this-indent (car indent-stack))) (when (listp this-indent) - (let ((val (calculate-lisp-indent - (or (car this-indent) starting-point)))) + ;; The state here is actually to the end of the + ;; previous line, but that's fine for our purposes. + ;; And continuing the parse to the next line would + ;; destroy element 2 (last sexp position) which + ;; `calculate-lisp-indent' needs. + (let ((val (calculate-lisp-indent state))) (setq this-indent (cond ((integerp val) -- 2.11.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 13 10:00:06 2017 Received: (at 25122) by debbugs.gnu.org; 13 Mar 2017 14:00:06 +0000 Received: from localhost ([127.0.0.1]:53966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cnQW5-00073B-LE for submit@debbugs.gnu.org; Mon, 13 Mar 2017 10:00:06 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:34850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cnQW3-00072A-B6 for 25122@debbugs.gnu.org; Mon, 13 Mar 2017 10:00:04 -0400 Received: by mail-io0-f194.google.com with SMTP id f103so13330883ioi.2 for <25122@debbugs.gnu.org>; Mon, 13 Mar 2017 07:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=NlFl3SwmYkAbsWws8V9o2UCUv9NbAO+JLbaiS282FNo=; b=J8yumtg11gcLcUmwEpinJEPTYvF8EPoTKmJV6XdPZzzwhaf6WswvoxPV+/ABHwleLW tNL+Q189Q9Mkljn1hCOTqxq620//4Mgw3QvFQ0r7yD33BuBnGUrFCl4wkB7LLJU/1r0T BQ+29pD10z0cpJHRlfaThTiusNNIoLKJbzlIWVS437GBOSjZAG3nWPyEdxdQwNITC8ma F8bcgBrT2R+RKKYtFjY3jaoGQ3p8pRylF3LpOBafJMr46UhkXNnfwqelQ6AXSBctLTVm h6/hG0q6WJPw1D+fDG7VA//YLHB2kqAFizYmYe0+gvtwAJhCxix4sRNv7rp2lcLNBD5U y7pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=NlFl3SwmYkAbsWws8V9o2UCUv9NbAO+JLbaiS282FNo=; b=K2zDWrPPlVW0lfFMp51xZPMl6qzuVAaectTKbemr9NjwlV3RMPfEcQ1m3qPzAiv3dY CcJAbUBFfwpg6+2OYDPMz7QpawkdpIHfkvOmzGfnFpMIImBDTTUvEUQXnsGVtefU6JPJ xkt7l8NTD+pLcHsRXVXMfg8DucLTP3oDPoFNyV/FR4x75EsKmthr2x7Kk2+jDgUfjtkk jD7HOmdSQAXYBUb9CCGtEktDrlQ0KTmo6LvoJDRfO8jt7zdxD1hnJhiZOYT2O3Uk3BsU RnYqff9Rd+xCU4V8GjEikxg9jCQPLk4MF4JvPWLo+BW7BoibHk4uzTaEPrnjY1ULctiK B+Gw== X-Gm-Message-State: AMke39k6y7fqxCQq/mWFyPoOm93eqeFmeIKC+ZPyRGZpX3ZLmvHXEjECBGLLcJiVjnahnA== X-Received: by 10.107.136.41 with SMTP id k41mr31118497iod.160.1489413597642; Mon, 13 Mar 2017 06:59:57 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id a197sm3699691ita.1.2017.03.13.06.59.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Mar 2017 06:59:56 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> Date: Mon, 13 Mar 2017 10:01:13 -0400 In-Reply-To: <87lgs97pg5.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Mon, 13 Mar 2017 00:47:38 -0400") Message-ID: <87innd6zti.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.8 (/) --=-=-= Content-Type: text/plain npostavs@users.sourceforge.net writes: > npostavs@users.sourceforge.net writes: > >> Also, this doesn't really solve the performance problem, it just makes >> it much less likely to occur, e.g., (pp (list load-history)) is still >> slow. > > Okay, I think I found the real fix now: Missed a corner case. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=v2-0001-Don-t-reparse-the-sexp-in-indent-sexp-Bug-25122.patch Content-Description: patch >From b8dd372f65ce8979324c00b12a9ae767c1ffabda Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sun, 12 Mar 2017 23:59:19 -0400 Subject: [PATCH v2] Don't reparse the sexp in indent-sexp (Bug#25122) * lisp/emacs-lisp/lisp-mode.el (calculate-lisp-indent): Let PARSE-START be a parse state that can be reused. (indent-sexp): Pass the running parse state to calculate-lisp-indent instead of the sexp beginning position. Saving the CONTAINING-SEXP-START returned by `calculate-lisp-indent' is no longer needed. * test/lisp/emacs-lisp/lisp-mode-tests.el (indent-sexp): Add blank line to test case. --- lisp/emacs-lisp/lisp-mode.el | 71 ++++++++++++++++++--------------- test/lisp/emacs-lisp/lisp-mode-tests.el | 5 ++- 2 files changed, 42 insertions(+), 34 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index eb07c18b03..3fefb69066 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -781,6 +781,10 @@ calculate-lisp-indent If the value is nil, that means don't change the indentation because the line starts inside a string. +PARSE-START may be a buffer position to start parsing from, or a +parse state as returned by calling `parse-partial-sexp' up to the +beginning of the current line. + The value can also be a list of the form (COLUMN CONTAINING-SEXP-START). This means that following lines at the same level of indentation should not necessarily be indented the same as this line. @@ -794,12 +798,14 @@ calculate-lisp-indent (desired-indent nil) (retry t) calculate-lisp-indent-last-sexp containing-sexp) - (if parse-start - (goto-char parse-start) - (beginning-of-defun)) - ;; Find outermost containing sexp - (while (< (point) indent-point) - (setq state (parse-partial-sexp (point) indent-point 0))) + (cond ((or (markerp parse-start) (integerp parse-start)) + (goto-char parse-start)) + ((null parse-start) (beginning-of-defun)) + (t (setq state parse-start))) + (unless state + ;; Find outermost containing sexp + (while (< (point) indent-point) + (setq state (parse-partial-sexp (point) indent-point 0)))) ;; Find innermost containing sexp (while (and retry state @@ -1070,11 +1076,6 @@ indent-sexp ENDPOS is encountered." (interactive) (let* ((indent-stack (list nil)) - ;; If ENDPOS is non-nil, use beginning of defun as STARTING-POINT. - ;; If ENDPOS is nil, it is safe not to scan before point - ;; since every line we indent is more deeply nested than point is. - (starting-point (save-excursion (if endpos (beginning-of-defun)) - (point))) ;; Use `syntax-ppss' to get initial state so we don't get ;; confused by starting inside a string. We don't use ;; `syntax-ppss' in the loop, because this is measurably @@ -1093,16 +1094,21 @@ indent-sexp (save-excursion (while (< (point) endpos) ;; Parse this line so we can learn the state to indent the - ;; next line. - (while (progn - (setq state (parse-partial-sexp - last-syntax-point (progn (end-of-line) (point)) - nil nil state)) - ;; Skip over newlines within strings. - (nth 3 state)) - (setq state (parse-partial-sexp (point) (point-max) - nil nil state 'syntax-table)) - (setq last-syntax-point (point))) + ;; next line. Preserve element 2 of the state (last sexp) for + ;; `calculate-lisp-indent'. + (let ((last-sexp (nth 2 state))) + (while (progn + (setq state (parse-partial-sexp + last-syntax-point (progn (end-of-line) (point)) + nil nil state)) + (setq last-sexp (or (nth 2 state) last-sexp)) + ;; Skip over newlines within strings. + (nth 3 state)) + (setq state (parse-partial-sexp (point) (point-max) + nil nil state 'syntax-table)) + (setq last-sexp (or (nth 2 state) last-sexp)) + (setq last-syntax-point (point))) + (setf (nth 2 state) last-sexp)) (setq next-depth (car state)) ;; If the line contains a comment indent it now with ;; `indent-for-comment'. @@ -1115,6 +1121,8 @@ indent-sexp (make-list (- init-depth next-depth) nil)) last-depth (- last-depth next-depth) next-depth init-depth)) + ;; Now indent the next line according to what we learned from + ;; parsing the previous one. (forward-line 1) (when (< (point) endpos) (let ((depth-delta (- next-depth last-depth))) @@ -1124,28 +1132,25 @@ indent-sexp (setq indent-stack (nconc (make-list depth-delta nil) indent-stack)))) (setq last-depth next-depth)) - ;; Now indent the next line according - ;; to what we learned from parsing the previous one. - (skip-chars-forward " \t") ;; But not if the line is blank, or just a comment (we ;; already called `indent-for-comment' above). + (skip-chars-forward " \t") (unless (or (eolp) (eq (char-syntax (char-after)) ?<)) - (let ((this-indent (car indent-stack))) - (when (listp this-indent) - (let ((val (calculate-lisp-indent - (or (car this-indent) starting-point)))) - (setq - this-indent + (indent-line-to + (or (car indent-stack) + ;; The state here is actually to the end of the + ;; previous line, but that's fine for our purposes. + ;; And parsing over the newline would only destroy + ;; element 2 (last sexp position). + (let ((val (calculate-lisp-indent state))) (cond ((integerp val) (setf (car indent-stack) val)) ((consp val) ; (COLUMN CONTAINING-SEXP-START) - (setf (car indent-stack) (cdr val)) (car val)) ;; `calculate-lisp-indent' only returns nil ;; when we're in a string, but this won't ;; happen because we skip strings above. - (t (error "This shouldn't happen!")))))) - (indent-line-to this-indent)))))))) + (t (error "This shouldn't happen!")))))))))))) (defun indent-pp-sexp (&optional arg) "Indent each line of the list starting just after point, or prettyprint it. diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el index 2801f23df6..848dd7ca3e 100644 --- a/test/lisp/emacs-lisp/lisp-mode-tests.el +++ b/test/lisp/emacs-lisp/lisp-mode-tests.el @@ -31,6 +31,9 @@ 1 2) 2) + (fun arg1 + + arg2) (1 \"string noindent\" (\"string2 @@ -58,7 +61,7 @@ (save-excursion (let ((n 0)) (while (not (eobp)) - (unless (looking-at "noindent") + (unless (looking-at "noindent\\|^[[:blank:]]*$") (insert (make-string n ?\s))) (cl-incf n) (forward-line)))) -- 2.11.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 15 22:53:17 2017 Received: (at 25122) by debbugs.gnu.org; 16 Mar 2017 02:53:17 +0000 Received: from localhost ([127.0.0.1]:57792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coLXR-0003mz-C3 for submit@debbugs.gnu.org; Wed, 15 Mar 2017 22:53:17 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:34206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coLXP-0003mh-2N for 25122@debbugs.gnu.org; Wed, 15 Mar 2017 22:53:15 -0400 Received: by mail-it0-f67.google.com with SMTP id r141so5049161ita.1 for <25122@debbugs.gnu.org>; Wed, 15 Mar 2017 19:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=MdPBWcA7Zs9nZl3pX2HPrHTur8ES56gcGrJ0XXcTpyw=; b=PRfk6HOqidWoYAaDFqVGk0OkNrJbBtbC+4i/u4U3YlApLk2efSCye8pI7M5vK3uDh6 SI4UiALfRV+2sp1n0GlMpxXFWO6Qv+mKiwgERoszvp64F8sMyhsx5e9KclKi//T5FBT3 ihmEbv+bzkLKci/W8/3g+xoYZ92RLl4NOCeBHamD7h25W3dsLjsO1HCJ/a8a1xVOAmLS brn7NKlgJPpBfDZOuNltB37Emn1igPWp/NpXtcPGl9TbBYZfKEE9hX5lBWnyGEQeuhMY FDedDvRogXULvFT3SZzvh2iofvGoL26sqrgYtX1QquIAzaqOweOuSd/pnM3o+7zRBSN7 dg+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=MdPBWcA7Zs9nZl3pX2HPrHTur8ES56gcGrJ0XXcTpyw=; b=Y+gAh0c86idayZSEVtgCXZ50d8RL9pVbVwgjdKAMpUCSUFDvo5wsktA+CvoA6TOYUe yON1qT/TAZu+o+YnNoHcGbezr1rxj+0LXoPLC8+G4AL7EsrsfW4w+lhXBDxUGu34LCWV zr4EuVH/Yaqg3vbpxrjwPgLXM369YgvxlJQGGtSg3UnMFi2HJdGHQuizWMnT0qV+xbZu ZClCSUoLbDxikAa2NKguzCGEPHUucOBf0IYoYtP6gAwHf7CxvPfsaO4WGpe4I/UACgXn zjCtf1nLzaqC8q7Zi1PgMbZsv57skq1Xx9z+R7vkff5rtrpcSqghhBVaF3Ai+z/zPp79 uX4Q== X-Gm-Message-State: AFeK/H38ekGqaW6P1FGwlvo0x3O2dbS/8VzWPH6oc+m1qGsa7FUhhhc2F0R8i/FCyhZ0gg== X-Received: by 10.36.58.207 with SMTP id m198mr8430657itm.31.1489632789483; Wed, 15 Mar 2017 19:53:09 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id w73sm2386822ioi.16.2017.03.15.19.53.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Mar 2017 19:53:08 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> <87innd6zti.fsf@users.sourceforge.net> Date: Wed, 15 Mar 2017 22:54:24 -0400 In-Reply-To: <87innd6zti.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Mon, 13 Mar 2017 10:01:13 -0400") Message-ID: <878to653tr.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --=-=-= Content-Type: text/plain >> npostavs@users.sourceforge.net writes: >> >> Okay, I think I found the real fix now: Same issue with indent-region. The gains are not so dramatic for typical lisp code that has normal size sexps, but C-x h C-M-\ on subr.el's text runs twice as fast for me with the new lisp-indent-region function. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v2-0002-Remove-ignored-argument-from-lisp-indent-line.patch Content-Description: patch >From 1a5464d36582b5efcea43aac37bf0b9ddd4c1ff1 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 15 Mar 2017 21:59:13 -0400 Subject: [PATCH v2 2/4] Remove ignored argument from lisp-indent-line * lisp/emacs-lisp/lisp-mode.el (lisp-indent-line): Remove WHOLE-EXP argument, the behvior has long since been handled in `indent-for-tab-command'. --- lisp/emacs-lisp/lisp-mode.el | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 3fefb69066..7eb8b986be 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -744,11 +744,9 @@ lisp-indent-function :type 'function :group 'lisp) -(defun lisp-indent-line (&optional _whole-exp) - "Indent current line as Lisp code. -With argument, indent any additional lines of the same expression -rigidly along with this one." - (interactive "P") +(defun lisp-indent-line () + "Indent current line as Lisp code." + (interactive) (let ((indent (calculate-lisp-indent)) shift-amt (pos (- (point-max) (point))) (beg (progn (beginning-of-line) (point)))) -- 2.11.1 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v2-0003-Add-new-lisp-indent-region-that-doesn-t-reparse-t.patch Content-Description: patch >From 9cf8f32910c0c899f108c3907d099a18fff2cec4 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 15 Mar 2017 22:27:27 -0400 Subject: [PATCH v2 3/4] Add new `lisp-indent-region' that doesn't reparse the code. * lisp/emacs-lisp/lisp-mode.el (lisp-indent-region): New function, like `indent-region-line-by-line' but additionally keep a running parse state to avoid reparsing the code repeatedly. (lisp-indent-line): Take optional PARSE-STATE argument, pass it to `calculate-lisp-indent'. (lisp-mode-variables): Set `indent-region-function' to `lisp-indent-region'. --- lisp/emacs-lisp/lisp-mode.el | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 7eb8b986be..7577267903 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -586,6 +586,7 @@ lisp-mode-variables ;; I believe that newcomment's auto-fill code properly deals with it -stef ;;(set (make-local-variable 'adaptive-fill-mode) nil) (setq-local indent-line-function 'lisp-indent-line) + (setq-local indent-region-function 'lisp-indent-region) (setq-local outline-regexp ";;;\\(;* [^ \t\n]\\|###autoload\\)\\|(") (setq-local outline-level 'lisp-outline-level) (setq-local add-log-current-defun-function #'lisp-current-defun-name) @@ -744,10 +745,38 @@ lisp-indent-function :type 'function :group 'lisp) -(defun lisp-indent-line () +(defun lisp-indent-region (start end) + "Indent region as Lisp code, efficiently." + (save-excursion + (setq end (copy-marker end)) + (goto-char start) + ;; The default `indent-region-line-by-line' doesn't hold a running + ;; parse state, which forces each indent call to reparse from the + ;; beginning. That has O(n^2) complexity. + (let* ((parse-state (syntax-ppss start)) + (last-syntax-point start) + (pr (unless (minibufferp) + (make-progress-reporter "Indenting region..." (point) end)))) + (while (< (point) end) + (unless (and (bolp) (eolp)) + (lisp-indent-line parse-state)) + (forward-line 1) + (let ((last-sexp (nth 2 parse-state))) + (setq parse-state (parse-partial-sexp last-syntax-point (point) + nil nil parse-state)) + ;; It's important to preserve last sexp location for + ;; `calculate-lisp-indent'. + (unless (nth 2 parse-state) + (setf (nth 2 parse-state) last-sexp)) + (setq last-syntax-point (point))) + (and pr (progress-reporter-update pr (point)))) + (and pr (progress-reporter-done pr)) + (move-marker end nil)))) + +(defun lisp-indent-line (&optional parse-state) "Indent current line as Lisp code." (interactive) - (let ((indent (calculate-lisp-indent)) shift-amt + (let ((indent (calculate-lisp-indent parse-state)) shift-amt (pos (- (point-max) (point))) (beg (progn (beginning-of-line) (point)))) (skip-chars-forward " \t") -- 2.11.1 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v2-0004-lisp-emacs-lisp-lisp-mode.el-indent-sexp-Clean-up.patch Content-Description: patch >From 4dbe8fd84064b1b3fed4188f0a2a84de5550cf11 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 15 Mar 2017 22:35:47 -0400 Subject: [PATCH v2 4/4] * lisp/emacs-lisp/lisp-mode.el (indent-sexp): Clean up marker. --- lisp/emacs-lisp/lisp-mode.el | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 7577267903..4fa9eb97de 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -1112,12 +1112,13 @@ indent-sexp (next-depth init-depth) (last-depth init-depth) (last-syntax-point (point))) - (unless endpos - ;; Get error now if we don't have a complete sexp after point. - (save-excursion (forward-sexp 1) - ;; We need a marker because we modify the buffer - ;; text preceding endpos. - (setq endpos (point-marker)))) + ;; We need a marker because we modify the buffer + ;; text preceding endpos. + (setq endpos (copy-marker + (if endpos endpos + ;; Get error now if we don't have a complete sexp + ;; after point. + (save-excursion (forward-sexp 1) (point))))) (save-excursion (while (< (point) endpos) ;; Parse this line so we can learn the state to indent the @@ -1177,7 +1178,8 @@ indent-sexp ;; `calculate-lisp-indent' only returns nil ;; when we're in a string, but this won't ;; happen because we skip strings above. - (t (error "This shouldn't happen!")))))))))))) + (t (error "This shouldn't happen!")))))))))) + (move-marker endpos nil))) (defun indent-pp-sexp (&optional arg) "Indent each line of the list starting just after point, or prettyprint it. -- 2.11.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 17 23:52:11 2017 Received: (at 25122) by debbugs.gnu.org; 18 Apr 2017 03:52:11 +0000 Received: from localhost ([127.0.0.1]:53319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d0KBW-00048m-HF for submit@debbugs.gnu.org; Mon, 17 Apr 2017 23:52:11 -0400 Received: from mail-io0-f173.google.com ([209.85.223.173]:36801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d0KBV-00048X-9w for 25122@debbugs.gnu.org; Mon, 17 Apr 2017 23:52:10 -0400 Received: by mail-io0-f173.google.com with SMTP id o22so54579013iod.3 for <25122@debbugs.gnu.org>; Mon, 17 Apr 2017 20:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=3hYMgKYSeO0+jB7tNiNvUFNgokEJXoz9+Lj9ej8VNds=; b=gqkLFI9GCu3metJoQ0bmtlS4GVFydf7dlIiV8T6nIY76y4jmAhKZywMVOWOYMPvh3d O2B3zzHmr1zJrY3zGeUEQM6VEKZhAn1CjTGl1YqHl2GRp30+mDxLMy+phUptCXcpFUi8 FTWDlTa5iQBbvC2xuBc+KsekYRmcvwvbH3oBw2g2qw+5qwOxyviFcuB4tx43420QMFQg +VJQ/liotQ2dVI7bZfPCqUvSEvgNT2u1RJgCFTfVj8xX0dTexx/C/QgvpJ6eIQPDFa0t yaepEBwrs6FpkJ9dksezGdozg5GUG1Ucu2ev4oMzfu+OM9br1+jtDnzUe0iA4AoizCBQ j4/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=3hYMgKYSeO0+jB7tNiNvUFNgokEJXoz9+Lj9ej8VNds=; b=YVLX9VcNqaDzNmkmtsgCi61ludmI1ywLonUpJWsDcr55Oa8EBm1ge39LsLysM09Fo4 FoZjKOsAT7zMhmZpO+WExl5Nmg6LpYjYRa/h1YnnWhhjMxrI4wlnAumd3H8wakPk+0N+ n8vOkFfA4oU+7awKw1rdUO+sXvm3PE6HNWqpZkf64/sElLrWng6zSsitOtKK/aNzozyO UnLmrq6SvWe9pLAhXNvqD5qnAasiTKZ06appeqWSdcQuzgOHCr5GSSHoZWygY1juJecx 6D0I/r5vu7lR2+pMSU2PCsMU/3hB+kDUxHTQ+ND2fOLNAVw6oGSR/PpFrAsnx7udfbY7 INIg== X-Gm-Message-State: AN3rC/5SV8Fw1WQ100rBs5m21hvGmMOM+hh+mtLeC24pJfOYAtIA6wt5 aaYhiYIqDXcv1g== X-Received: by 10.107.20.87 with SMTP id 84mr12885905iou.59.1492487523711; Mon, 17 Apr 2017 20:52:03 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id j193sm5905204ioe.59.2017.04.17.20.52.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 17 Apr 2017 20:52:02 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> <87innd6zti.fsf@users.sourceforge.net> <878to653tr.fsf@users.sourceforge.net> Date: Mon, 17 Apr 2017 23:53:30 -0400 In-Reply-To: <878to653tr.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Wed, 15 Mar 2017 22:54:24 -0400") Message-ID: <87fuh6s75x.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --=-=-= Content-Type: text/plain npostavs@users.sourceforge.net writes: >>> npostavs@users.sourceforge.net writes: >>> >>> Okay, I think I found the real fix now: > > Same issue with indent-region. The gains are not so dramatic for > typical lisp code that has normal size sexps, but C-x h C-M-\ on > subr.el's text runs twice as fast for me with the new lisp-indent-region > function. Had some test failures due to some corner cases, should all be fixed now. I think this is the final patch set. This also fixes lisp-indent-region and lisp-indent-line to not indent string literal contents. I intend to close this bug as fixed after merging these, as this does fix the performance bug. I will probably pursue the alternate pretty printer separately; it doesn't help performance (after the indent-sexp performance is fixed), but gives prettier results in some cases. The threading idea may also be worth looking at, but can also be considered separately, as this bug report is already long enough. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v3-0001-Don-t-reparse-the-sexp-in-indent-sexp-Bug-25122.patch Content-Description: patch >From 9ae3809189d08c15d64363c963eeeae62efae242 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sun, 12 Mar 2017 23:59:19 -0400 Subject: [PATCH v3 1/4] Don't reparse the sexp in indent-sexp (Bug#25122) * lisp/emacs-lisp/lisp-mode.el (calculate-lisp-indent): Let PARSE-START be a parse state that can be reused. (indent-sexp): Pass the running parse state to calculate-lisp-indent instead of the sexp beginning position. Saving the CONTAINING-SEXP-START returned by `calculate-lisp-indent' is no longer needed. Don't bother stopping if we don't descend below init-depth, since we now alway scan the whole buffer (via syntax-ppss) anyway. * test/lisp/emacs-lisp/lisp-mode-tests.el (indent-sexp): Add blank line to test case. --- lisp/emacs-lisp/lisp-mode.el | 76 +++++++++++++++++---------------- test/lisp/emacs-lisp/lisp-mode-tests.el | 5 ++- 2 files changed, 43 insertions(+), 38 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 2e6e13f1dd..607a4c3d11 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -785,6 +785,10 @@ calculate-lisp-indent If the value is nil, that means don't change the indentation because the line starts inside a string. +PARSE-START may be a buffer position to start parsing from, or a +parse state as returned by calling `parse-partial-sexp' up to the +beginning of the current line. + The value can also be a list of the form (COLUMN CONTAINING-SEXP-START). This means that following lines at the same level of indentation should not necessarily be indented the same as this line. @@ -798,12 +802,14 @@ calculate-lisp-indent (desired-indent nil) (retry t) calculate-lisp-indent-last-sexp containing-sexp) - (if parse-start - (goto-char parse-start) - (beginning-of-defun)) - ;; Find outermost containing sexp - (while (< (point) indent-point) - (setq state (parse-partial-sexp (point) indent-point 0))) + (cond ((or (markerp parse-start) (integerp parse-start)) + (goto-char parse-start)) + ((null parse-start) (beginning-of-defun)) + (t (setq state parse-start))) + (unless state + ;; Find outermost containing sexp + (while (< (point) indent-point) + (setq state (parse-partial-sexp (point) indent-point 0)))) ;; Find innermost containing sexp (while (and retry state @@ -1074,11 +1080,6 @@ indent-sexp ENDPOS is encountered." (interactive) (let* ((indent-stack (list nil)) - ;; If ENDPOS is non-nil, use beginning of defun as STARTING-POINT. - ;; If ENDPOS is nil, it is safe not to scan before point - ;; since every line we indent is more deeply nested than point is. - (starting-point (save-excursion (if endpos (beginning-of-defun)) - (point))) ;; Use `syntax-ppss' to get initial state so we don't get ;; confused by starting inside a string. We don't use ;; `syntax-ppss' in the loop, because this is measurably @@ -1087,8 +1088,7 @@ indent-sexp (init-depth (car state)) (next-depth init-depth) (last-depth init-depth) - (last-syntax-point (point)) - (real-endpos endpos)) + (last-syntax-point (point))) (unless endpos ;; Get error now if we don't have a complete sexp after point. (save-excursion (forward-sexp 1) @@ -1098,16 +1098,21 @@ indent-sexp (save-excursion (while (< (point) endpos) ;; Parse this line so we can learn the state to indent the - ;; next line. - (while (progn - (setq state (parse-partial-sexp - last-syntax-point (progn (end-of-line) (point)) - nil nil state)) - ;; Skip over newlines within strings. - (nth 3 state)) - (setq state (parse-partial-sexp (point) (point-max) - nil nil state 'syntax-table)) - (setq last-syntax-point (point))) + ;; next line. Preserve element 2 of the state (last sexp) for + ;; `calculate-lisp-indent'. + (let ((last-sexp (nth 2 state))) + (while (progn + (setq state (parse-partial-sexp + last-syntax-point (progn (end-of-line) (point)) + nil nil state)) + (setq last-sexp (or (nth 2 state) last-sexp)) + ;; Skip over newlines within strings. + (nth 3 state)) + (setq state (parse-partial-sexp (point) (point-max) + nil nil state 'syntax-table)) + (setq last-sexp (or (nth 2 state) last-sexp)) + (setq last-syntax-point (point))) + (setf (nth 2 state) last-sexp)) (setq next-depth (car state)) ;; If the line contains a comment indent it now with ;; `indent-for-comment'. @@ -1120,9 +1125,9 @@ indent-sexp (make-list (- init-depth next-depth) nil)) last-depth (- last-depth next-depth) next-depth init-depth)) + ;; Now indent the next line according to what we learned from + ;; parsing the previous one. (forward-line 1) - (when (and (not real-endpos) (<= next-depth init-depth)) - (goto-char endpos)) (when (< (point) endpos) (let ((depth-delta (- next-depth last-depth))) (cond ((< depth-delta 0) @@ -1131,28 +1136,25 @@ indent-sexp (setq indent-stack (nconc (make-list depth-delta nil) indent-stack)))) (setq last-depth next-depth)) - ;; Now indent the next line according - ;; to what we learned from parsing the previous one. - (skip-chars-forward " \t") ;; But not if the line is blank, or just a comment (we ;; already called `indent-for-comment' above). + (skip-chars-forward " \t") (unless (or (eolp) (eq (char-syntax (char-after)) ?<)) - (let ((this-indent (car indent-stack))) - (when (listp this-indent) - (let ((val (calculate-lisp-indent - (or (car this-indent) starting-point)))) - (setq - this-indent + (indent-line-to + (or (car indent-stack) + ;; The state here is actually to the end of the + ;; previous line, but that's fine for our purposes. + ;; And parsing over the newline would only destroy + ;; element 2 (last sexp position). + (let ((val (calculate-lisp-indent state))) (cond ((integerp val) (setf (car indent-stack) val)) ((consp val) ; (COLUMN CONTAINING-SEXP-START) - (setf (car indent-stack) (cdr val)) (car val)) ;; `calculate-lisp-indent' only returns nil ;; when we're in a string, but this won't ;; happen because we skip strings above. - (t (error "This shouldn't happen!")))))) - (indent-line-to this-indent)))))))) + (t (error "This shouldn't happen!")))))))))))) (defun indent-pp-sexp (&optional arg) "Indent each line of the list starting just after point, or prettyprint it. diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el index 8e3f2e185c..27f0bb5ec1 100644 --- a/test/lisp/emacs-lisp/lisp-mode-tests.el +++ b/test/lisp/emacs-lisp/lisp-mode-tests.el @@ -31,6 +31,9 @@ 1 2) 2) + (fun arg1 + + arg2) (1 \"string noindent\" (\"string2 @@ -58,7 +61,7 @@ (save-excursion (let ((n 0)) (while (not (eobp)) - (unless (looking-at "noindent") + (unless (looking-at "noindent\\|^[[:blank:]]*$") (insert (make-string n ?\s))) (cl-incf n) (forward-line)))) -- 2.11.1 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v3-0002-lisp-emacs-lisp-lisp-mode.el-indent-sexp-Clean-up.patch Content-Description: patch >From b14e7d088ef23074841cb1384503dd60c1e939e9 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 15 Mar 2017 22:35:47 -0400 Subject: [PATCH v3 2/4] * lisp/emacs-lisp/lisp-mode.el (indent-sexp): Clean up marker. --- lisp/emacs-lisp/lisp-mode.el | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 607a4c3d11..810fc95614 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -1089,12 +1089,13 @@ indent-sexp (next-depth init-depth) (last-depth init-depth) (last-syntax-point (point))) - (unless endpos - ;; Get error now if we don't have a complete sexp after point. - (save-excursion (forward-sexp 1) - ;; We need a marker because we modify the buffer - ;; text preceding endpos. - (setq endpos (point-marker)))) + ;; We need a marker because we modify the buffer + ;; text preceding endpos. + (setq endpos (copy-marker + (if endpos endpos + ;; Get error now if we don't have a complete sexp + ;; after point. + (save-excursion (forward-sexp 1) (point))))) (save-excursion (while (< (point) endpos) ;; Parse this line so we can learn the state to indent the @@ -1154,7 +1155,8 @@ indent-sexp ;; `calculate-lisp-indent' only returns nil ;; when we're in a string, but this won't ;; happen because we skip strings above. - (t (error "This shouldn't happen!")))))))))))) + (t (error "This shouldn't happen!")))))))))) + (move-marker endpos nil))) (defun indent-pp-sexp (&optional arg) "Indent each line of the list starting just after point, or prettyprint it. -- 2.11.1 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v3-0003-Remove-ignored-argument-from-lisp-indent-line.patch Content-Description: patch >From 6cbe2b3acbb22e75b373d39d716ab4dc1a0f276f Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 15 Mar 2017 21:59:13 -0400 Subject: [PATCH v3 3/4] Remove ignored argument from lisp-indent-line * lisp/emacs-lisp/lisp-mode.el (lisp-indent-line): Remove WHOLE-EXP argument, the behavior has long since been handled in `indent-for-tab-command'. Also remove redundant `beg' and `shift-amt' variables and use `indent-line-to'. --- lisp/emacs-lisp/lisp-mode.el | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 810fc95614..89d5659f30 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -748,14 +748,12 @@ lisp-indent-function :type 'function :group 'lisp) -(defun lisp-indent-line (&optional _whole-exp) - "Indent current line as Lisp code. -With argument, indent any additional lines of the same expression -rigidly along with this one." - (interactive "P") - (let ((indent (calculate-lisp-indent)) shift-amt - (pos (- (point-max) (point))) - (beg (progn (beginning-of-line) (point)))) +(defun lisp-indent-line () + "Indent current line as Lisp code." + (interactive) + (let ((indent (calculate-lisp-indent)) + (pos (- (point-max) (point)))) + (beginning-of-line) (skip-chars-forward " \t") (if (or (null indent) (looking-at "\\s<\\s<\\s<")) ;; Don't alter indentation of a ;;; comment line @@ -767,11 +765,7 @@ lisp-indent-line ;; as comment lines, not as code. (progn (indent-for-comment) (forward-char -1)) (if (listp indent) (setq indent (car indent))) - (setq shift-amt (- indent (current-column))) - (if (zerop shift-amt) - nil - (delete-region beg (point)) - (indent-to indent))) + (indent-line-to indent)) ;; If initial point was within line's indentation, ;; position after the indentation. Else stay at same point in text. (if (> (- (point-max) pos) (point)) -- 2.11.1 --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v3-0004-Add-new-lisp-indent-region-that-doesn-t-reparse-t.patch Content-Description: patch >From d2f3101d88eb9601a52c06d1171c413fc23e3d8d Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 15 Mar 2017 22:27:27 -0400 Subject: [PATCH v3 4/4] Add new `lisp-indent-region' that doesn't reparse the code. Both `lisp-indent-region' and `lisp-indent-line' now use `syntax-ppss' to get initial state, so they will no longer indent string literal contents. * lisp/emacs-lisp/lisp-mode.el (lisp-ppss): New function, like `syntax-ppss', but with a more dependable item 2. (lisp-indent-region): New function, like `indent-region-line-by-line' but additionally keep a running parse state to avoid reparsing the code repeatedly. Use `lisp-ppss' to get initial state. (lisp-indent-line): Take optional PARSE-STATE argument, pass it to `calculate-lisp-indent', use `lisp-ppss' if not given. (lisp-mode-variables): Set `indent-region-function' to `lisp-indent-region'. --- lisp/emacs-lisp/lisp-mode.el | 48 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 89d5659f30..54d916887c 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -594,6 +594,7 @@ lisp-mode-variables ;; I believe that newcomment's auto-fill code properly deals with it -stef ;;(set (make-local-variable 'adaptive-fill-mode) nil) (setq-local indent-line-function 'lisp-indent-line) + (setq-local indent-region-function 'lisp-indent-region) (setq-local outline-regexp ";;;\\(;* [^ \t\n]\\|###autoload\\)\\|(") (setq-local outline-level 'lisp-outline-level) (setq-local add-log-current-defun-function #'lisp-current-defun-name) @@ -748,12 +749,51 @@ lisp-indent-function :type 'function :group 'lisp) -(defun lisp-indent-line () +(defun lisp-ppss (&optional pos) + "Return Parse-Partial-Sexp State at POS, defaulting to point. +Like to `syntax-ppss' but includes the character address of the +last complete sexp in the innermost containing list at position +2 (counting from 0). This is important for lisp indentation." + (unless pos (setq pos (point))) + (let ((pss (syntax-ppss pos))) + (if (nth 9 pss) + (parse-partial-sexp (car (last (nth 9 pss))) pos) + pss))) + +(defun lisp-indent-region (start end) + "Indent region as Lisp code, efficiently." + (save-excursion + (setq end (copy-marker end)) + (goto-char start) + ;; The default `indent-region-line-by-line' doesn't hold a running + ;; parse state, which forces each indent call to reparse from the + ;; beginning. That has O(n^2) complexity. + (let* ((parse-state (lisp-ppss start)) + (last-syntax-point start) + (pr (unless (minibufferp) + (make-progress-reporter "Indenting region..." (point) end)))) + (while (< (point) end) + (unless (and (bolp) (eolp)) + (lisp-indent-line parse-state)) + (forward-line 1) + (let ((last-sexp (nth 2 parse-state))) + (setq parse-state (parse-partial-sexp last-syntax-point (point) + nil nil parse-state)) + ;; It's important to preserve last sexp location for + ;; `calculate-lisp-indent'. + (unless (nth 2 parse-state) + (setf (nth 2 parse-state) last-sexp)) + (setq last-syntax-point (point))) + (and pr (progress-reporter-update pr (point)))) + (and pr (progress-reporter-done pr)) + (move-marker end nil)))) + +(defun lisp-indent-line (&optional parse-state) "Indent current line as Lisp code." (interactive) - (let ((indent (calculate-lisp-indent)) - (pos (- (point-max) (point)))) - (beginning-of-line) + (let ((pos (- (point-max) (point))) + (indent (progn (beginning-of-line) + (calculate-lisp-indent (or parse-state (lisp-ppss)))))) (skip-chars-forward " \t") (if (or (null indent) (looking-at "\\s<\\s<\\s<")) ;; Don't alter indentation of a ;;; comment line -- 2.11.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 22 14:24:06 2017 Received: (at 25122) by debbugs.gnu.org; 22 Apr 2017 18:24:07 +0000 Received: from localhost ([127.0.0.1]:34668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d1zhW-0005s6-Na for submit@debbugs.gnu.org; Sat, 22 Apr 2017 14:24:06 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:33651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d1zhT-0005rP-9s; Sat, 22 Apr 2017 14:24:03 -0400 Received: by mail-it0-f66.google.com with SMTP id z67so5860187itb.0; Sat, 22 Apr 2017 11:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=EmOKstKSIMAmqrj6uwsHED6XBgSQ74VP3nzKYsKlZ6Q=; b=VmIWyi4T6aAjuAdfzWrf+j0/kbWZYD1APu7GFv6NGgQ1fKkPbIRckojRiYyr7THot/ j9n1lUFBWWCeVu7X+9eY7iIQQaZupDGocZ/oqQNrvxKIJekM0ONq7vSJWJ3T9Q/dnW3R 07ObNeGY53Zcq+eBFPoA81xAEVPd6C+264SY6Lz+E2t7lp92Bn+1SkVQxJISzJlGaGo2 DRCD2ALUrF7V6N8DQNDaP2HEiSCmYDSOv3jrsSsHBcvMkEDz1iouBI5nEDFD85FkkTnX 4KjpwM9Wt6zp8gGO8JNDJf3/rsINxg7+YMFfUJpCV5ktbC/Y4CYKGwjArtvATe4NVmeg kJBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=EmOKstKSIMAmqrj6uwsHED6XBgSQ74VP3nzKYsKlZ6Q=; b=ZMCt55TuRWfTL5qRaDMeshpew6lAi/s42l4Ub4gs4uNV4NgTmwyd8WXIzqe02XbUVQ mL//foI18pnsg74fkWfP5Gs/ASPFL9ZXMU8gNAxFHzII/rQ00c0SZr+Ew73Mn62e5L0Y df1tntQIB2XUFbief6lr/twmCdIri5aNA3/SPpVAMyG+rCUmyHlt0nR4k1nwzL1/ojrp +Ug4HmHyEZ1JEcr6b31dDAHG6i9sjlt09DgFDbrjFFbwcB8Tssyph3ZOflEF6C1MUlU3 w0bXiSGhgJDog1awDEqqzNjn9C3M4iWk8yv80ZHUAHxjGNGQJerSgmOicmuI9hdTdaOU 1tDQ== X-Gm-Message-State: AN3rC/7iyNEfMbiiRkjCXO9vEirvm2CoPPYi5Dq4gSfErQ815WtVa4nD aCBU9prW6FXUKw== X-Received: by 10.36.95.144 with SMTP id r138mr5227406itb.11.1492885437857; Sat, 22 Apr 2017 11:23:57 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id e191sm2233256ita.9.2017.04.22.11.23.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 22 Apr 2017 11:23:57 -0700 (PDT) From: npostavs@users.sourceforge.net To: Thierry Volpiatto Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> <87innd6zti.fsf@users.sourceforge.net> <878to653tr.fsf@users.sourceforge.net> <87fuh6s75x.fsf@users.sourceforge.net> Date: Sat, 22 Apr 2017 14:25:27 -0400 In-Reply-To: <87fuh6s75x.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Mon, 17 Apr 2017 23:53:30 -0400") Message-ID: <87mvb8paeg.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org, Stefan Monnier , Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) tags 25122 fixed close 25122 26.1 quit npostavs@users.sourceforge.net writes: > > I intend to close this bug as fixed after merging these, as this does > fix the performance bug. Pushed to master. [1: 6fa9cc0593]: 2017-04-22 14:18:46 -0400 ; Merge: improve indent-sexp and lisp-indent-region performance http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6fa9cc0593150a318f0e08e69ec10672d548a7c1 [2: 4713dd425b]: 2017-04-22 14:09:58 -0400 Add new `lisp-indent-region' that doesn't reparse the code. http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4713dd425beac5cb459704e67dcb8f6faf714375 [3: 2f6769f9cd]: 2017-04-22 14:09:58 -0400 Remove ignored argument from lisp-indent-line http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2f6769f9cdb799e880fdcc09057353a0a2349bfc [4: 8bb5d7adaf]: 2017-04-22 14:09:57 -0400 * lisp/emacs-lisp/lisp-mode.el (indent-sexp): Clean up marker. http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8bb5d7adaf45264900385530c7f76175ba490a77 [5: 43c84577a3]: 2017-04-22 14:09:57 -0400 Don't reparse the sexp in indent-sexp (Bug#25122) http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=43c84577a3055d5ddf1f5d1b999e6ecca6139f60 From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 25 23:58:04 2017 Received: (at 25122) by debbugs.gnu.org; 26 Apr 2017 03:58:04 +0000 Received: from localhost ([127.0.0.1]:40411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3E5c-0000rF-16 for submit@debbugs.gnu.org; Tue, 25 Apr 2017 23:58:04 -0400 Received: from mout.web.de ([212.227.17.12]:61016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3E5Z-0000qk-8G for 25122@debbugs.gnu.org; Tue, 25 Apr 2017 23:58:01 -0400 Received: from drachen.dragon ([88.73.21.103]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MHowb-1d6nWN0Shp-003e3Y; Wed, 26 Apr 2017 05:57:42 +0200 From: Michael Heerdegen To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> <87innd6zti.fsf@users.sourceforge.net> <878to653tr.fsf@users.sourceforge.net> <87fuh6s75x.fsf@users.sourceforge.net> <87mvb8paeg.fsf@users.sourceforge.net> Date: Wed, 26 Apr 2017 05:57:47 +0200 In-Reply-To: <87mvb8paeg.fsf@users.sourceforge.net> (npostavs's message of "Sat, 22 Apr 2017 14:25:27 -0400") Message-ID: <87d1bzlt1g.fsf@drachen> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:43F2CflsX4zfqntz/uueH9p7/aiVignFl6+xjhEM/1aIM09QVyg NAm+kaWSXXi7rJCWlXRMZmMODFpyrQwNFpotgb+tA/7fazD1LgJiaRhyO4zTqp/WMxVB6j2 gTQP1waJ8IKGgST87Jq0u2kjoalf2CNsCU+mVz8wxuhwnre3NrUyL+6oCKXc2tvWSvtcbyK QFqXIjye4S4hVvJ6BXdIw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Sh3Yb0vxIHc=:hbI3MrRQDJscTNBldJnDJC f5o/KMl6SlbiYfD7QEe933vDhM4Ruo8jksOPB71XcB5Wn6dm5gpw01ZBQ0+L4iSUvZ7JN80Zu +LRSjoQoUBAhAZ0wIQcR2vcteW0ZG0tcvqlIdQwCYRCBqcCJM/wV8yT72KqG7x0SX/4rwWlR6 bbe5SUuM7Oy32DtDxEFupdiBMqbosa4CUviVBi+W9vyP9MCabwzNYgh/YPH3LTtz1xk8bwAq1 6CwrUKRbKQnarkclE5dZC3SLNzXhxvnDh277bl/duN7hROdXow68mGo0syFEkwMagvoFL4i8l EDACRu9vDg8NI8YhRwdfgapSiylDLwvTvHgT6SPolXxzyN+ePIFgMC1TMt35Nx3yuvY9DFaHr 1KCSdRuYB+2naPUN7rDK9iKNAD4qMT/4SIfaaZFGNzCypHIyUduEYTZUo+nNOReGaFVxFfUc0 OBXGcs03to4YcmYLu8xUULGarK/nBvJByG4auOUYJg2fIJ5MpDSYyf7/vkUrua5n7jeByc/W4 VNfR/FCDOaaRWwqGAqtE3x5hAILjrx9Wr4ywnSbyynFVdvKul6O/8F7w8PwfeeGRYzCDFan+l GIW+36gJnZ0G5AMZAT4u8ZVExWnGgDuLYPbyJLucMZL0e7FV2TuLPHYi4GiMYi56TFiYirzMh k3qcmgRib1OpA9FZHJPYMy01NvKE3P71ScP9TC4C9taXEpbAcMkaIqOztGA4ce75YT8/0TdMm XOfI/4X9q4mbd7UGaYXvNz/E2J8EJiOreD6MCGKfOOpeCzsLpBRPJSLj/ivRbE2NFFtY4XcZT mgGvSIR X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Noam, > > I intend to close this bug as fixed after merging these, as this does > > fix the performance bug. I have a question: how much performance gain can I expect from your changes? My use case is the following: "el-search" has now an occur-like operation mode. It copies all matches (i.e. s-expressions) into an *El Occur* buffer. Matches can be tiny (like `1') or arbitrarily large. Since most expressions don't start at column 0 in their source buffer (unless they are top-level), I have to remove the amount of additional indentation from all but the first line of a match. Well - not from all, that's where it gets complicated - there are cases where this is wrong, like in strings and some comments. To have a sane solution, I just used `indent-region' to reindent the expression in the occur buffer. This works great, but `indent-region' was so slow that it took up to 50 percent of the whole running time of the occur search. With an naive alternative approach (just remove additional indentation from lines where it makes sense (whereby finding out whether it "makes sense" involves running syntax scanning)), I get an improvement of a factor around five or ten relative to `indent-region' for reindenting. Would you expect your improved `indent-region' is fast enough now so that it makes sense that I switch back to it in my code? Is the running time now something close to O(number of lines to indent)? Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 26 06:35:27 2017 Received: (at 25122) by debbugs.gnu.org; 26 Apr 2017 10:35:27 +0000 Received: from localhost ([127.0.0.1]:40600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3KIB-0006AD-Bz for submit@debbugs.gnu.org; Wed, 26 Apr 2017 06:35:27 -0400 Received: from mout.web.de ([212.227.17.11]:61457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3KI9-00069z-Ag for 25122@debbugs.gnu.org; Wed, 26 Apr 2017 06:35:25 -0400 Received: from drachen.dragon ([88.73.21.103]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LZvUH-1dp0JZ1nnJ-00loOe; Wed, 26 Apr 2017 12:35:04 +0200 From: Michael Heerdegen To: npostavs@users.sourceforge.net Subject: Re: bug#25122: 24.5; function describe-variable hangs on large variables References: <20161206022112.GF25778@E15-2016.optimum.net> <87twahk19y.fsf@gmail.com> <87d1h4fld5.fsf@users.sourceforge.net> <871sxkyv2m.fsf@gmail.com> <87mvcs8j7w.fsf@users.sourceforge.net> <87lgsbtxwe.fsf@gmail.com> <871su38ogm.fsf@users.sourceforge.net> <87d1dnrq96.fsf@gmail.com> <87wpbu7f9i.fsf@users.sourceforge.net> <87r32278wf.fsf@users.sourceforge.net> <87lgs97pg5.fsf@users.sourceforge.net> <87innd6zti.fsf@users.sourceforge.net> <878to653tr.fsf@users.sourceforge.net> <87fuh6s75x.fsf@users.sourceforge.net> <87mvb8paeg.fsf@users.sourceforge.net> <87d1bzlt1g.fsf@drachen> Date: Wed, 26 Apr 2017 12:35:06 +0200 In-Reply-To: <87d1bzlt1g.fsf@drachen> (Michael Heerdegen's message of "Wed, 26 Apr 2017 05:57:47 +0200") Message-ID: <87h91b4ftx.fsf@drachen> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:APp75JMBQe4x6oGk22V5sBAEQ72zn0LiKRYF2cgJC0PJG+jt/x7 4pLXIbgAVNm6tiW+5x+rcxGQHPeUBH3nmkJqr4C8SsdA5OO4S0CvpbNUyWTdt/0rWEwT0B7 lXYJ3F9lCi5Qe3TY32t4cSWoDJQpKRAjpEjgBNEoVtsJpkEyrtEsV+Mi2H9p4xTCI2peUei weTGxiFbs/1iftEWy5fkA== X-UI-Out-Filterresults: notjunk:1;V01:K0:C4ZkcSwc9/M=:zbkIi7cAnVtlPVk/kYAZ1E VfArM964UN+UvJz4ePwxUyyda6SsZci644Qhoh6/gT+6mxQl7TId1nHvJD6KxMVvUxokEtswx xXs93lKT/xXrX+9lmCQypvfcjRsWyAZVGPS0pRgAmCYRIV81dCtNjvJ9/1UCOmStWjTy3jTX/ 2Ebr5adIT7O9s/Da8smgJKeCtye3A8Nk2FDXESVi94QrrHbd8fEMZjn9J1IYA3jO/fTuDLyWi v8XwboPoVFAm1gbNSg44exRV8PnKucWhwMzBH2gBYJikH8gk5wE2ELHL1/ijgZwBCH46FTqIu WlKm1H82P0Y+TVOF/jSugntcWLSvthiFC4+5lfQj0N/C35pVnowYC8YVQ6Y9+/UMlzi+KGYN9 f6oJWMs0f5bSA4Ng305SfQayUaT5p0SACe24pof8YuPsYYs9r6XJUvQKELY1YOQ7MWRzjvvzb wp/K1DZvyhMVptxo5qr0S9Skhxjeoj5PV0EwC1m1BP4jHYAKVfNoXupttaHXANgF3BWgEU2uj 6WJJAd5Ng0QNheWDe/Ma43SIHQ8dU7rXoh8aO/b5loUfB7CGFlci4h7Eb0pXFSFToUpJd3GP4 1m9YmTjNks2iXkHhKi7tAGL7OWqeXuUgbgY39nTgdorwUyX0cgGv+DjyG8DsEFFrynWt9arFo XJ6GXSJijxJWXcQ2XurDIjBxOMdGXAszJiVotrOBWL70wIVnxAweygRyks0FvCLj1vms6YBAB GamqADCyXdy2nple5zGQy9ZEy5Vlvvu9KcFlJRrvpNzdwgobn9ucUwR07QzF3tv66Uq9283Hv xvoVxIH X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 25122 Cc: 25122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Michael Heerdegen writes: > Would you expect your improved `indent-region' is fast enough now so > that it makes sense that I switch back to it in my code? Is the > running time now something close to O(number of lines to indent)? After some tests, I think it is fast enough for my scenario. And I see from the comments in the code that you addressed the complexity problem. Michael. From unknown Fri Jun 20 05:37:29 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 24 May 2017 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator