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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 20 May 2013 20:25:55 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Karl Fogel <kfogel@red-bean.com>, yates@digitalsignallabs.com, 
>  emacs-devel@gnu.org
> 
> >    M->
> >    C-p
> >
> > and count the seconds it takes to perform the second command.
> >
> > What Emacs does behind the scenes is go to the beginning of the
> > previous _physical_ line (which is quite fast in this case), and the
> > go all the way down the humongously long line, one character at a
> > time, until it finds the place to put the cursor.  Unless we make
> > radical changes in this algorithm, how can anyone expect reasonable
> > performance from this?
> 
> This is pretty ugly because both previous-line and next-line uses
> Fforward_line, which uses scan_newline, which _does not_ use newline
> cache :-(.

Emacs doesn't use previous-line and next-line in the scenario I
described.  It uses back_to_previous_visible_line_start, which in turn
uses find_newline_no_quit, and that does use the cache.

But you are missing the point.  First, this particular file has only
one line, so not using the cache means we only miss a single newline.
More importantly, even if we do cache newlines, how will that help us
with such long lines?  It should be clear that traversing such lines
from left to right, one character at a time, is _the_ bottleneck, not
how fast can we find the previous/next newline.