bug#38407: 27.0.50; infinite loop with display of large file without newlines

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Pieter van Oostrum

1) Load a large file, that contains no newlines. I used a 100KB json
file from my Firefox profile (but loaded as a text file)
2) set visual-line-mode aka Word wrap
3) scroll up (<next> scroll-up-command)

The scrolling is very slow, and the further in the file you come, the
slower it becomes. During that time, Emacs consumes close to 100% CPU.
At a certain moment it took me half an our for one scroll operation.
When I went to the end of the buffer (M-> end-of-buffer), Emacs looped
virtually forever. I decided to kill it after 12 hours.

In another experiment, I repeatedly did a scroll-up-command, followed by
the shell command 'date >> display.log'. I repeated this with a keyboard
macro.
The written times indicate that in the beginning the time for a
scroll-up goes up linearly until more than a minute, and then Emacs get
stuck.




In GNU Emacs 27.0.50 (build 1, i686-apple-darwin10.0.0, NS appkit-1561.61 Version 10.13.6 (Build 17G9016))
 of 2019-11-27 built on cochabamba.vanoostrum.org
Repository revision: 4eb7db5d4b84708912c63a77569c8adeeff6c640
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1561
System Description:  Mac OS X 10.13.6

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
 [Beginning of history; no preceding item]
Visual-Line mode enabled

Configured using:
 'configure --build i686-apple-darwin10.0.0 --without-dbus --with-ns
 build_alias=i686-apple-darwin10.0.0 'CFLAGS=-pipe -march=nocona'
 PKG_CONFIG_PATH=/usr/X11R6/pkgconfig/:/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/'

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS PDUMPER LCMS2

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_NL.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded 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
threads kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 47303 8427)
 (symbols 48 6678 1)
 (strings 32 16380 1383)
 (string-bytes 1 518147)
 (vectors 16 10228)
 (vector-slots 8 141557 8968)
 (floats 8 20 39)
 (intervals 56 193 0)
 (buffers 1000 13))

--
Pieter van Oostrum <[hidden email]>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Phil Sainty
See whether M-x global-so-long-mode makes things more tolerable?

Extremely long lines are a problem for Emacs, but so-long.el can
help significantly in some situations.

If you enable that, and then visit your file, it should switch to
so-long-mode.  It won't prevent the redisplay getting relatively
slower the deeper you navigate into a very long line, but it should
make navigating in the early stages of the file much faster, and
help to some extent throughout (but I would still expect displaying
the end of the line to be painful).

M-x so-long-commentary has all of the details.


-Phil




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Phil Sainty
In reply to this post by Pieter van Oostrum
On 2019-11-28 10:52, Pieter van Oostrum wrote:
> I used a 100KB json file from my Firefox profile
> (but loaded as a text file)

I missed that bit, so I should add that global-so-long-mode doesn't
care about text-mode by default.  It mostly targets programming modes
(.json filenames included), but you can customize so-long-target-modes
to include text-mode if you think you're likely to encounter such
files in text-mode in practice.

However I wouldn't expect a 100K file in text-mode to cause anything
remotely like the degree of performance issue you've encountered.  I
have a 256K single-line .txt file which suffers perceivable slow-downs
at the end of the file (in text-mode with visual-line-mode enabled),
but nothing remotely so catastrophic as you're reporting.  On my
machine, I'd estimate less than a half-second delay when scrolling,
so the difference is several orders of magnitude.

Are you seeing that starting from "emacs -Q" ?


-Phil




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Phil Sainty
In reply to this post by Pieter van Oostrum
On 2019-11-28 10:52, Pieter van Oostrum wrote:
> I used a 100KB json file from my Firefox profile

Out of interest I went looking for large JSON files in my own Firefox
profiles, and the largest one I could find was an "extensions.json"
which was also roughly 100K.  Curiously enough, everything was indeed
dramatically slower than normal in that buffer, even in so-long-mode.

I also observed that many different human languages were present in
the text, so I thought that bi-directional text processing might be a
factor -- and indeed setting the debug option bidi-display-reordering
to nil in that buffer made a *very* dramatic improvement to
performance.

Similarly, performance was good after using M-x find-file-literally
to visit the file.

I am guessing that this is also what is happening for you?


-Phil




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Pieter van Oostrum
Phil Sainty wrote:

 > On 2019-11-28 10:52, Pieter van Oostrum wrote:
 > > I used a 100KB json file from my Firefox profile
 >
 > Out of interest I went looking for large JSON files in my own Firefox
 > profiles, and the largest one I could find was an "extensions.json"
 > which was also roughly 100K.  Curiously enough, everything was indeed
 > dramatically slower than normal in that buffer, even in so-long-mode.
 >
 > I also observed that many different human languages were present in
 > the text, so I thought that bi-directional text processing might be a
 > factor -- and indeed setting the debug option bidi-display-reordering
 > to nil in that buffer made a *very* dramatic improvement to
 > performance.
 >
 > Similarly, performance was good after using M-x find-file-literally
 > to visit the file.
 >
 > I am guessing that this is also what is happening for you?

It was exactly that file that caused the problem. I copied it to a .txt file to see if the problem might have been caused by the Javascript mode, and it didn't make any difference.

Normally I wouldn't open such a bizarre file, but I was doing an 'rgrep' on my home directory, and this was one of the files that came up in the grep results. When I was scrolling though the *grep* buffer, I got this problem. Then I decided to just open the file, to eliminate the possibility that grep-mode was one of the causes.

And yes, I checked it all with emacs -Q.

I forgot to mention that when I set debug-on-quit, a Quit indicated Emacs was in redisplay_internal.

--
Pieter van Oostrum <[hidden email]>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
In reply to this post by Phil Sainty
> Date: Thu, 28 Nov 2019 14:22:07 +1300
> From: Phil Sainty <[hidden email]>
> Cc: [hidden email]
>
> On 2019-11-28 10:52, Pieter van Oostrum wrote:
> > I used a 100KB json file from my Firefox profile
>
> Out of interest I went looking for large JSON files in my own Firefox
> profiles, and the largest one I could find was an "extensions.json"
> which was also roughly 100K.  Curiously enough, everything was indeed
> dramatically slower than normal in that buffer, even in so-long-mode.
>
> I also observed that many different human languages were present in
> the text, so I thought that bi-directional text processing might be a
> factor -- and indeed setting the debug option bidi-display-reordering
> to nil in that buffer made a *very* dramatic improvement to
> performance.

AFAICT, it isn't the bidi reordering in general, it's the BPA part of
the reordering -- that file has many embedded bracket characters.

I've added a new variable bidi-inhibit-bpa.  Try setting it non-nil,
and I think you will see performance very similar to disabling the
reordering entirely.  I guess that's another variable for so-long-mode
to futz with...

> Similarly, performance was good after using M-x find-file-literally
> to visit the file.

It makes very little sense to visit a text file with many non-ASCII
characters using find-file-literally, IMO.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
In reply to this post by Pieter van Oostrum
> Date: Thu, 28 Nov 2019 07:51:33 +0100
> From: Pieter van Oostrum <[hidden email]>
> Cc: [hidden email]
>
> Normally I wouldn't open such a bizarre file, but I was doing an 'rgrep' on my home directory, and this was one of the files that came up in the grep results. When I was scrolling though the *grep* buffer, I got this problem. Then I decided to just open the file, to eliminate the possibility that grep-mode was one of the causes.
>
> And yes, I checked it all with emacs -Q.

As an aside, using Text mode for such files, and visual-line-mode on
top of that, is exactly the opposite of what one should do to make
redisplay performance better.  Text mode resets
bidi-paragraph-direction to nil, which makes redisplay work harder
because it needs to find the beginning of the current paragraph each
time redisplay starts.  And visual-line-mode makes redisplay a bit
slower, because of the need to find a suitable point to break the
line.

So I suggest to use the default mode for visiting JSON files.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Pieter van Oostrum
Eli Zaretskii wrote:

 > > Date: Thu, 28 Nov 2019 07:51:33 +0100
 > > From: Pieter van Oostrum <[hidden email]>
 > > Cc: [hidden email]
 > >
 > > Normally I wouldn't open such a bizarre file, but I was doing an 'rgrep' on my home directory, and this was one of the files that came up in the grep results. When I was scrolling though the *grep* buffer, I got this problem. Then I decided to just open the file, to eliminate the possibility that grep-mode was one of the causes.
 > >
 > > And yes, I checked it all with emacs -Q.
 >
 > As an aside, using Text mode for such files, and visual-line-mode on
 > top of that, is exactly the opposite of what one should do to make
 > redisplay performance better.  Text mode resets
 > bidi-paragraph-direction to nil, which makes redisplay work harder
 > because it needs to find the beginning of the current paragraph each
 > time redisplay starts.  And visual-line-mode makes redisplay a bit
 > slower, because of the need to find a suitable point to break the
 > line.
 >
 > So I suggest to use the default mode for visiting JSON files.

I did open it as .json, and also enabled global-so-long-mode, but still no joy.
The real culprit is visual-line-mode, because without it, it can scroll through the file, albeit slowly. But it does finish, whereas with visual-line-mode it keeps swallowing CPU-time, at least for hours.
The really bad thing is that it can't be interrupted. ^G does not really stop it. So when you encounter this problem the only way out is to externally abort Emacs, thereby risking to lose your work. And all the hassle to restart and set up what you were doing.

As I encounter this problem in real life with rgrep, I can't always avoid it. I am doing a massive cleanup in my home directory, and with rgrep I will occasionally encounter these nasty files. It happened a couple of times in the last weeks.

In Emacs 26, it is also slow, but the redisplay comes to an end, so I see this as a kind of regression. The timing with Emacs 26 is very similar to that in Emacs 27, except that it doesn't hang at the end. So my impression is that the real difference is when the scrolling reaches the end of the file. That also happens with M-> (end-of-buffer), which hangs indefinitely (or at least a long time that is virtually indistinguishable from indefinitely) in Emacs 27, but it does finish in Emacs 26.
--
Pieter van Oostrum <[hidden email]>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
> Date: Thu, 28 Nov 2019 19:30:50 +0100
> From: Pieter van Oostrum <[hidden email]>
> Cc: [hidden email],
>     [hidden email]
>
> In Emacs 26, it is also slow, but the redisplay comes to an end, so I see this as a kind of regression. The timing with Emacs 26 is very similar to that in Emacs 27, except that it doesn't hang at the end. So my impression is that the real difference is when the scrolling reaches the end of the file. That also happens with M-> (end-of-buffer), which hangs indefinitely (or at least a long time that is virtually indistinguishable from indefinitely) in Emacs 27, but it does finish in Emacs 26.

I don't think there's any difference in this aspect between Emacs 26
and 27.  I see the same problem in both, FWIW, and I definitely didn't
wait for hours for redisplay to finish, let alone saw it "hang
indefinitely", even in an unoptimized build of Emacs 27 on a very slow
machine.  In my case it took something like 15 minutes.  I don't
understand why you see such long times.  Of course, I tried this with
a different JSON file than you did, so maybe there's something in your
file that causes even more slowdown.

In any case, try the latest master after setting bidi-inhibit-bpa to
non-nil.  In my testing, this is as fast as Emacs 23, i.e. no bidi
reordering at all, give or take some 10%.

And if you want the fastest display possible, use Fundamental mode,
not Text.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Pieter van Oostrum
Eli Zaretskii wrote:

 > > Date: Thu, 28 Nov 2019 19:30:50 +0100
 > > From: Pieter van Oostrum <[hidden email]>
 > > Cc: [hidden email],
 > >     [hidden email]
 > >
 > > In Emacs 26, it is also slow, but the redisplay comes to an end, so I see this as a kind of regression. The timing with Emacs 26 is very similar to that in Emacs 27, except that it doesn't hang at the end. So my impression is that the real difference is when the scrolling reaches the end of the file. That also happens with M-> (end-of-buffer), which hangs indefinitely (or at least a long time that is virtually indistinguishable from indefinitely) in Emacs 27, but it does finish in Emacs 26.
 >
 > I don't think there's any difference in this aspect between Emacs 26
 > and 27.  I see the same problem in both, FWIW, and I definitely didn't
 > wait for hours for redisplay to finish, let alone saw it "hang
 > indefinitely", even in an unoptimized build of Emacs 27 on a very slow
 > machine.  In my case it took something like 15 minutes.  I don't
 > understand why you see such long times.  Of course, I tried this with
 > a different JSON file than you did, so maybe there's something in your
 > file that causes even more slowdown.
 >
 > In any case, try the latest master after setting bidi-inhibit-bpa to
 > non-nil.  In my testing, this is as fast as Emacs 23, i.e. no bidi
 > reordering at all, give or take some 10%.
 >
 > And if you want the fastest display possible, use Fundamental mode,
 > not Text.
 >
 >
I have tried the latest version with so-long-mode, bidi-inhibit-bpa set to t, and the json file. Still hanging for a long time. Maybe it makes a difference that I am on MacOS?
--
Pieter van Oostrum <[hidden email]>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
> Date: Thu, 28 Nov 2019 23:09:57 +0100
> From: Pieter van Oostrum <[hidden email]>
> Cc: [hidden email],
>     [hidden email]
>
> I have tried the latest version with so-long-mode, bidi-inhibit-bpa
> set to t, and the json file. Still hanging for a long time.

You mean, you see no difference regardless of setting
bidi-inhibit-bpa?  Not even without so-long-mode in the picture?

> Maybe it makes a difference that I am on MacOS?

Unlikely.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Phil Sainty
I've just pulled from master and recompiled, and in my own tests
setting bidi-inhibit-bpa to t improves performance greatly.

On my machine, with the particular extensions.json file I'm using:

* In js-mode, scrolling at the end of the file incurs a ~6s delay.

* In so-long-mode (without bidi-inhibit-bpa), the same thing incurs a
  ~5s delay -- not much of an improvement.

* After setting bidi-inhibit-bpa to t in so-long-variable-overrides
  and revisiting the file, the same thing incurs only a ~1s delay.

* Using M-: (setq-local bidi-inhibit-bpa t) in json-mode (i.e. without
  using so-long) likewise makes things a great deal faster (but the
  combination with so-long is better still).

Scrolling at the top of the file in so-long-mode with the new option
set is more or less instantaneous.  Without the new option that is
also quite slow (if not to the same extent as the end of the file).

In short, this enhancement seems very effective to me (thank you Eli),
so I will push the addition to so-long.el shortly.


-Phil




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
> Cc: Pieter van Oostrum <[hidden email]>, [hidden email]
> From: Phil Sainty <[hidden email]>
> Date: Sat, 30 Nov 2019 00:48:22 +1300
>
> In short, this enhancement seems very effective to me (thank you Eli),
> so I will push the addition to so-long.el shortly.

Thanks.  But note that setting bidi-inhibit-bpa non-nil will help
significantly only for files that are likely to have a lot of bracket
characters, especially if they are nested.  So maybe do that in
so-long.el only for modes where this is likely to happen, if not by
actually counting such characters.  E.g., I wouldn't recommend doing
that in Text mode, since there it might cause incorrect display
without any real benefits.

Characters that I call "bracket" for this purpose are listed in
admin/unidata/BidiBrackets.txt (a file we import from the UCD).
Significantly, the "<>" pair is not there, so files with lots of those
particular brackets will not be affected by this issue.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Dmitry Gutov
In reply to this post by Phil Sainty
On 29.11.2019 13:48, Phil Sainty wrote:
> * Using M-: (setq-local bidi-inhibit-bpa t) in json-mode (i.e. without
>    using so-long) likewise makes things a great deal faster (but the
>    combination with so-long is better still)

Interesting!

Should we consider setting this value in `prog-mode`, then? For all its
derivatives.

And in compilation-mode, where it would make the most difference for me
personally.

I think in all of these cases we're unlikely to see bidirectional text.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
> Cc: Pieter van Oostrum <[hidden email]>, [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Fri, 29 Nov 2019 15:48:14 +0200
>
> Should we consider setting this value in `prog-mode`, then? For all its
> derivatives.

No, because programming-language modes include strings and comments,
where the correct rendering is important.

This variable should not be set non-nil unless the display engine is
abysmally slow.  In all other cases doing so is giving up correct
display while gaining nothing, because in "sensible" buffers the BPA
implementation is fast enough.

> I think in all of these cases we're unlikely to see bidirectional text.

I don't think "unlikely" is a good enough reason to do what you
suggest by default.  Emacs by default should produce correct display
of all scripts it supports, even in unlikely use cases.

Please don't make me regret I added this variable (or the bidi display
in general).



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Dmitry Gutov
On 29.11.2019 16:26, Eli Zaretskii wrote:
> No, because programming-language modes include strings and comments,
> where the correct rendering is important.

What about just compilation modes, then?

This is where I have routinely seen display slowdown because of long lines.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
> Cc: [hidden email], [hidden email], [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Fri, 29 Nov 2019 16:31:44 +0200
>
> On 29.11.2019 16:26, Eli Zaretskii wrote:
> > No, because programming-language modes include strings and comments,
> > where the correct rendering is important.
>
> What about just compilation modes, then?
>
> This is where I have routinely seen display slowdown because of long lines.

Are there a lot of parentheses/braces there? are they nested?

This variable will only have any visible effect when both of the
following conditions are true:

  . a physical line is very long
  . the line includes many parentheses and/or braces, especially if
    they are nested

If these conditions are not true, the variable will have no tangible
effect on redisplay performance.

Compilation buffers show errors and warnings, and this can easily
include strings.  For example, a code line that calls 'message' in
Lisp or 'printf' in C usually includes a string.  We don't want those
strings to be displayed incorrectly, unless displaying them correctly
takes a preposterous amount of time, at least not by default.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Dmitry Gutov
On 29.11.2019 17:03, Eli Zaretskii wrote:
> Are there a lot of parentheses/braces there? are they nested?

Almost never.

> This variable will only have any visible effect when both of the
> following conditions are true:
>
>    . a physical line is very long
>    . the line includes many parentheses and/or braces, especially if
>      they are nested
>
> If these conditions are not true, the variable will have no tangible
> effect on redisplay performance.

Guess I got over-excited, sorry. If I ever find performance benefits in
compilation buffers with this variable on, will report back.



Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Pieter van Oostrum
In reply to this post by Eli Zaretskii
Yes, I mean no difference. I started it late in the evening, and the next morning it was still running. I haven’t tried without so-long-mode. I am a few days from home without my laptop, so I can’t do any more testing at the moment.

--
Pieter van Oostrum

Op 29 nov. 2019 om 08:12 heeft Eli Zaretskii <[hidden email]> het volgende geschreven:

>> Date: Thu, 28 Nov 2019 23:09:57 +0100
>> From: Pieter van Oostrum <[hidden email]>
>> Cc: [hidden email],
>>    [hidden email]
>>
>> I have tried the latest version with so-long-mode, bidi-inhibit-bpa
>> set to t, and the json file. Still hanging for a long time.
>
> You mean, you see no difference regardless of setting
> bidi-inhibit-bpa?  Not even without so-long-mode in the picture?
>
>> Maybe it makes a difference that I am on MacOS?
>
> Unlikely.




Reply | Threaded
Open this post in threaded view
|

bug#38407: 27.0.50; infinite loop with display of large file without newlines

Eli Zaretskii
In reply to this post by Dmitry Gutov
> Cc: [hidden email], [hidden email], [hidden email]
> From: Dmitry Gutov <[hidden email]>
> Date: Fri, 29 Nov 2019 18:53:16 +0200
>
> On 29.11.2019 17:03, Eli Zaretskii wrote:
> > Are there a lot of parentheses/braces there? are they nested?
>
> Almost never.

That's what I thought.

> Guess I got over-excited, sorry. If I ever find performance benefits in
> compilation buffers with this variable on, will report back.

Thanks, that would help finding opportunities for redisplay
optimizations.



12