Re: Performance degradation from long lines

[Phil Sainty]

On 13/07/19 8:07 PM, Eli Zaretskii wrote:
> One comment I have is that disabling bidi-display-reordering should
> probably be removed from the defaults, because doing so puts the
> display engine in a state that is not being tested, and can cause
> inconsistencies and even bugs (because some portions of the code
> were written under the assumption that this variable is never nil).
>
> OTOH, I'd suggest setting bidi-paragraph-direction to 'left-to-right
> by default when so-long-mode is turned on.

That sounds good to me.  I wasn't aware that nil was an invalid value
for bidi-display-reordering.  I would suggest that its docstring be
updated in this regard.  Currently the doc is just "Non-nil means
reorder bidirectional text for display in the visual order." which to
me implies that value of nil is ok.


> Also, I don't understand why the defaults disable
> display-line-number-mode, it AFAIK does not slow down redisplay in
> any significant ways.  Do you have any evidence it should be
> disabled in buffers with long lines?

No, I'd simply included it along with the older line-numbering minor
modes.  I believe I can see a *very* slight difference, depending on
the state of display-line-number-mode, when moving around the visual
lines in a ~1MB line; however it's not significant, so I don't object
to removing it from the list.

I'm not sure that there's a benefit to the end-user in having line-
numbering enabled in such a file, though (which was the other reason
I went ahead and added all of those modes).

Some of the default minor modes are in the list because I felt the
features they provided would be redundant in a long-lines situation
(or redundant with font-lock-mode disabled), rather than because I'd
done benchmarking and established that they were notable CPU hogs.

I'd concluded that any mode or feature which scans buffer contents in
order to highlight things would be reasonable to disable by default,
and my general approach has been to err on the side of being overly
conservative in order to provide maximum benefit in the really extreme
cases.

I'm certain that the default settings can be improved though, so I'm
very happy for them to be discussed, and I hope that people will do
some experimentation in their own configs and recommend changes and
additions to the defaults, so that 27.1 ships with better coverage in
general -- the current defaults really only reflect things which I've
used personally.


> IME, truncate-lines sometimes makes display of long lines _faster_,
> so I'm not sure we should disable that by default.

This should stay.  The combination of truncate-lines being disabled
and line-move-visual being enabled is a tremendous benefit when the
user tries to move vertically from an extremely long line to the next
line.  With truncated lines, Emacs will have to scan to the end of the
line (one of my test files is a 19M JSON file in a single line*),
whereas with the settings I've used the user can happily move up and
down in the early parts of the file with no problems at all.

(*) You can find that file in this Stack Overflow question:
https://emacs.stackexchange.com/q/598 (see the 'wget' command).


-Phil