Re: Performance degradation from long lines

[mithraeum]

On Thursday, October 25, 2018 10:18 AM, Michael Heerdegen wrote:
>
> BTW (I already discussed this with Eli some time ago), we already have a
> solution in Emacs: longlines.el. It's obsoleted and a bit complicated,
> but something like ...

I just tested this solution on a 268K minified JSON file with 272307
characters on one line, and it worked amazingly well compared to the
status quo of Emacs freezing when it encounters files with long lines
even a tiny fraction of that length.

It opened in a total of about 5 seconds, with it taking about 2 seconds
before it prompted me as to whether to open it in longline mode or not,
and about 3 more seconds to open the rest.

At that point I had a fully font-locked version of the file opened
in a JSON mode buffer.

This made me very happy, and I think I wouldn't mind living with
this solution as is until the root cause is solved, especially
if I could get it to work on compilation-mode buffers as well,
which I anticipate should be just a matter of adding it to a
compilation-mode hook.

I also tested this solution on a 663K minified JSON file with 671209
characters on one line, and this one took a little over a minute
to open because it had a couple of long lines on the first screen,
with each line measuring over 1000 characters.  This is still better
than what I'm used to, and once I was able to control-g to a useable
buffer after just 30 seconds.

There are two main issues with this solution:

First, that it's still slow when there are some long lines in the
resulting buffer.

Second, that there is no indication in resulting buffer as to where
the end of each real line is.  I think Emacs has some ways to provide
visual indicators of line endings, so I might try some of those out
and see how they work with this mode.

This still doesn't fix the root issue, but as a workaround it looks
pretty good.