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

[Eli Zaretskii]

> Date: Wed, 22 May 2013 07:10:38 +0200
> Cc: address@hidden, address@hidden, address@hidden,
>         address@hidden
> From: Ulrich Mueller <address@hidden>
> 
> >>>>> On Tue, 21 May 2013, Eli Zaretskii wrote:
> 
> >> 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.
> 
> Sure, the example with 16 MB in one line is unrealistic. I made it so,
> simply because I wanted the times to be long enough to be measurable
> with a stop watch.
> 
> But wouldn't the factors between 23.4 and 24.3 be similar for more
> realistic examples?

Define "realistic".

The definition I used (and still do) is "where Emacs 23 provided
adequate behavior people wouldn't complain about."  In each such case
which I found or which was described to me, if Emacs 24 slowed things
down so they got past the humanly perceptible delay threshold, I
looked for and found optimizations that pushed Emacs 24 back below the
threshold, where the times used by Emacs 23 and 24 could not be
distinguished by humans.

If you find "realistic examples" by that definition, please by all
means report them as bugs.

But it was never a goal to make the performance of the bidirectional
display adequate where Emacs 23 wasn't, nor make it as inadequate as
Emacs 23.  That is another project, which needs to change display
algorithms and design on a different level.