[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performance degradation from long lines
From: |
Eli Zaretskii |
Subject: |
Re: Performance degradation from long lines |
Date: |
Sat, 13 Jul 2019 12:56:58 +0300 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Phil Sainty <address@hidden>
> Date: Sat, 13 Jul 2019 21:33:19 +1200
>
> 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.
It isn't invalid. It is useful for debugging the display code, but
using it in production session is dangerous, because it causes the
code to execute control-flow paths that aren't supported in
general-purpose usage.
> > 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.
In my measurements, the slow down is about 10% or less.
> 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).
Log files is one important use case where line numbers might be of
benefit.
> > 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.
If it's the combination that matters, I suggest to mention that in the
documentation (doc string, perhaps?), as I don't think this will be
otherwise evident.
Thanks.
- Re: Performance degradation from long lines, (continued)
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
- Re: Performance degradation from long lines, Stefan Kangas, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
- Re: Performance degradation from long lines, Stefan Kangas, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
- Re: Performance degradation from long lines, Stefan Kangas, 2019/07/13
- Re: Performance degradation from long lines, Phil Sainty, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
Re: Performance degradation from long lines, Phil Sainty, 2019/07/13
- Re: Performance degradation from long lines,
Eli Zaretskii <=
- Re: Performance degradation from long lines, Stefan Monnier, 2019/07/13
- Re: Performance degradation from long lines, Stefan Kangas, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
- Re: Performance degradation from long lines, Stefan Monnier, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/13
- Re: Performance degradation from long lines, Stefan Monnier, 2019/07/13
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/14
- Re: Performance degradation from long lines, Dmitry Gutov, 2019/07/15
- Re: Performance degradation from long lines, Eli Zaretskii, 2019/07/18
- Re: Performance degradation from long lines, Stefan Monnier, 2019/07/18