Re: emacs takes exhorbitantly long to read long, one-line files.

[Eli Zaretskii]

> Date: Tue, 21 May 2013 09:57:35 +0200
> Cc: Karl Fogel <address@hidden>,
>         Randy Yates <address@hidden>, address@hidden,
>         address@hidden
> From: Ulrich Mueller <address@hidden>
> 
> >   M->
> >   C-p
> 
> > and count the seconds it takes to perform the second command.
> 
> I've done this test for a file with one line of 16 MB, and I get the
> following times for the first and second commands (emacs -Q -nw in
> an 80x24 xterm):
> 
>   Emacs 23.4:   4 s /  9 s
>   Emacs 24.3:  16 s / 34 s
> 
> Is this degradation of performance expected?

I see no degradation in performance: both 4 sec and 6 sec, let alone 9
and 34, are the same as infinity.  You cannot have any useful editing
with such reaction times to a simple cursor movement command.  It is
therefore meaningless to compare such "performance" figures and draw
any conclusions from them.

Emacs 24 has got a bidirectional display engine.  Bidirectional
display needs to do much more work than the previous unidirectional
one in Emacs 23 and before.  In a nutshell, where the unidirectional
display simply incremented a pointer, the bidirectional display calls
a complex function that does some very non-trivial processing based on
the bidirectional class of each character.

Now, this sounds scary, but really isn't.  The bidirectional display
was optimized so that in all the known uses where the old display
provided reasonable performance, the new one does, too.  While the
bidi display is still slower than the unidirectional one, the
optimizations keep the slowdown in check, such that the delays are
below humanly perceptible threshold on reasonably modern and even
fairly old machines.  (I developed and debugged most of the code on a
7-year old machine that died less than a year ago.)

By contrast, use cases such as the above, where the old code performs
abysmally inadequately, were explicitly excluded from the scope of the
optimizations, because it doesn't make sense to punish 99.9% of users
on behalf of the rest.  And that is what you see above.

Emacs needs some non-trivial changes in display-related algorithms to
adequately support very long lines.  When those changes are designed
and implemented, I promise you that the bidirectional display will
keep up.