|
From: | Gemini Lasswell |
Subject: | bug#36566: 27.0.50; debug is sometimes horribly slow |
Date: | Mon, 05 Aug 2019 12:53:08 -0700 |
User-agent: | Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) |
Noam Postavsky <npostavs@gmail.com> writes: >> >> ...by modifying the logic in print_preprocess to not create a hash table >> if the top-level object is a string with no properties. > > This last idea sounds like a straightforward win to me, with no obvious > drawbacks. I mean, no point in allocating a hash table if we can > cheaply detect it will never be used, right? I made that change, and then, in studying the uses of print-number-table, found more cases in which allocated hash tables were never used. Since 2011 when byte-compile-disable-print-circle was marked obsolete and 2012 when commit 4ae29f89be changed the logic in print_object, the only time print-number-table gets used is when print-circle is non-nil. Because of that observation, I have added a patch which makes it so that print_preprocess is only called to create print-number-table when print_circle is non-nil. The patch also simplifies print_preprocess accordingly. In order to test that change thoroughly I added a couple new print tests and reorganized the existing print tests so that all functionality common between print.c and cl-print.el is now tested by the same tests, located in src/print-tests.el. Michael's use case is down to 0.7s on my machine.
0001-Improve-print-output-options-commands-in-backtrace-m.patch
Description: Text document
0002-Improve-performance-of-backtrace-printing-bug-36566.patch
Description: Text document
0003-Fix-unnecessary-hash-table-creation-in-cl-prin1-bug-.patch
Description: Text document
0004-Create-common-tests-for-print.c-and-cl-print.el.patch
Description: Text document
0005-Don-t-build-print-number-table-unless-it-will-be-use.patch
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |