unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
       [not found] ` <20220718185141.39F11C0F203@vcs2.savannah.gnu.org>
@ 2022-07-18 21:01   ` Stefan Monnier
  2022-07-18 21:04     ` Gregory Heytings
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2022-07-18 21:01 UTC (permalink / raw)
  To: emacs-devel; +Cc: Gregory Heytings

> diff --git a/etc/PROBLEMS b/etc/PROBLEMS
> index 14c1df25b1..4f02788ecd 100644
> --- a/etc/PROBLEMS
> +++ b/etc/PROBLEMS
> @@ -568,12 +568,6 @@ This can happen with CVS versions 1.12.8 and 1.12.9.  Upgrade to CVS
>  
>  ** Miscellaneous problems
>  
> -*** Editing files with very long lines is slow.
> -
> -For example, simply moving through a file that contains hundreds of
> -thousands of characters per line is slow, and consumes a lot of CPU.
> -This is a known limitation of Emacs with no solution at this time.

I wish this were true, but AFAIK the problem is still very much present.
We deal with it a bit better, but that doesn't mean the problem is gone.
In my tests, editing the end of a 1MB single-line JSON file is still
basically not an option, for example.


        Stefan




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-18 21:01   ` feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant Stefan Monnier
@ 2022-07-18 21:04     ` Gregory Heytings
  2022-07-18 21:36       ` Philip Kaludercic
  2022-07-21 11:50       ` Gregory Heytings
  0 siblings, 2 replies; 13+ messages in thread
From: Gregory Heytings @ 2022-07-18 21:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


>> -*** Editing files with very long lines is slow.
>> -
>> -For example, simply moving through a file that contains hundreds of
>> -thousands of characters per line is slow, and consumes a lot of CPU.
>> -This is a known limitation of Emacs with no solution at this time.
>
> I wish this were true, but AFAIK the problem is still very much present. 
> We deal with it a bit better, but that doesn't mean the problem is gone. 
> In my tests, editing the end of a 1MB single-line JSON file is still 
> basically not an option, for example.
>

Please try the feature branch, and you'll see the problem is gone.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-18 21:04     ` Gregory Heytings
@ 2022-07-18 21:36       ` Philip Kaludercic
  2022-07-18 21:46         ` Gregory Heytings
  2022-07-21 11:50       ` Gregory Heytings
  1 sibling, 1 reply; 13+ messages in thread
From: Philip Kaludercic @ 2022-07-18 21:36 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Stefan Monnier, emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

>>> -*** Editing files with very long lines is slow.
>>> -
>>> -For example, simply moving through a file that contains hundreds of
>>> -thousands of characters per line is slow, and consumes a lot of CPU.
>>> -This is a known limitation of Emacs with no solution at this time.
>>
>> I wish this were true, but AFAIK the problem is still very much
>> present. We deal with it a bit better, but that doesn't mean the
>> problem is gone. In my tests, editing the end of a 1MB single-line
>> JSON file is still basically not an option, for example.
>>
>
> Please try the feature branch, and you'll see the problem is gone.

I just tried it out, and while it certainly is an improvement, I noticed
that the performance appears to depend on the direction the point moves.
E.g. I generated a long line using

     yes abbbbbbbbbbbbbbbbbbbb | head -100000 | tr -d '\n' > long-line

and I could C-v to the end without any issues.  But M-v was
significantly slower.  The same applies to C-f vs. C-b.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-18 21:36       ` Philip Kaludercic
@ 2022-07-18 21:46         ` Gregory Heytings
  2022-07-19  4:10           ` Philip Kaludercic
  0 siblings, 1 reply; 13+ messages in thread
From: Gregory Heytings @ 2022-07-18 21:46 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Stefan Monnier, emacs-devel


>
> I just tried it out, and while it certainly is an improvement, I noticed 
> that the performance appears to depend on the direction the point moves. 
> E.g. I generated a long line using
>
> yes abbbbbbbbbbbbbbbbbbbb | head -100000 | tr -d '\n' > long-line
>
> and I could C-v to the end without any issues.  But M-v was 
> significantly slower.  The same applies to C-f vs. C-b.
>

Yes, the same is true without long lines, moving backward is slower than 
moving forward (but you probably meant C-p vs C-n, not C-f vs C-b). 
Please also read the relevant NEWS entry.  And try to edit that file with 
Emacs from master to see the difference.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-18 21:46         ` Gregory Heytings
@ 2022-07-19  4:10           ` Philip Kaludercic
  2022-07-19  5:21             ` Gregory Heytings
  0 siblings, 1 reply; 13+ messages in thread
From: Philip Kaludercic @ 2022-07-19  4:10 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Stefan Monnier, emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

>>
>> I just tried it out, and while it certainly is an improvement, I
>> noticed that the performance appears to depend on the direction the
>> point moves. E.g. I generated a long line using
>>
>> yes abbbbbbbbbbbbbbbbbbbb | head -100000 | tr -d '\n' > long-line
>>
>> and I could C-v to the end without any issues.  But M-v was
>> significantly slower.  The same applies to C-f vs. C-b.
>>
>
> Yes, the same is true without long lines, moving backward is slower
> than moving forward (but you probably meant C-p vs C-n, not C-f vs
> C-b).

No, I meant C-f and C-b, as the file contained only one line, but the
same applies to C-p and C-n.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-19  4:10           ` Philip Kaludercic
@ 2022-07-19  5:21             ` Gregory Heytings
  0 siblings, 0 replies; 13+ messages in thread
From: Gregory Heytings @ 2022-07-19  5:21 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: Stefan Monnier, emacs-devel


>> Yes, the same is true without long lines, moving backward is slower 
>> than moving forward (but you probably meant C-p vs C-n, not C-f vs 
>> C-b).
>
> No, I meant C-f and C-b,

That's rather surprising.  Even with Emacs on master, C-f and C-b can 
(almost) be used in such a file, and take the same amount of time.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-18 21:04     ` Gregory Heytings
  2022-07-18 21:36       ` Philip Kaludercic
@ 2022-07-21 11:50       ` Gregory Heytings
  2022-07-21 12:43         ` Stefan Kangas
                           ` (3 more replies)
  1 sibling, 4 replies; 13+ messages in thread
From: Gregory Heytings @ 2022-07-21 11:50 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


>> I wish this were true, but AFAIK the problem is still very much 
>> present. We deal with it a bit better, but that doesn't mean the 
>> problem is gone. In my tests, editing the end of a 1MB single-line JSON 
>> file is still basically not an option, for example.
>
> Please try the feature branch, and you'll see the problem is gone.
>

The feature has now landed on master.  You can now edit the end of a 1GB 
single-line file as if it were a 1KB file.  Enjoy!

(There are still a few limits, in particular font locking that should be 
turned off in files with long lines.  I will fix them soon.)



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-21 11:50       ` Gregory Heytings
@ 2022-07-21 12:43         ` Stefan Kangas
  2022-07-21 14:51         ` Daniel Martín
                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Stefan Kangas @ 2022-07-21 12:43 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Stefan Monnier, Emacs developers

Gregory Heytings <gregory@heytings.org> writes:

> The feature has now landed on master.  You can now edit the end of a 1GB
> single-line file as if it were a 1KB file.  Enjoy!

Yay!  Congratulations.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-21 11:50       ` Gregory Heytings
  2022-07-21 12:43         ` Stefan Kangas
@ 2022-07-21 14:51         ` Daniel Martín
  2022-07-21 15:25         ` Stefan Monnier
  2022-07-22 14:48         ` Lars Ingebrigtsen
  3 siblings, 0 replies; 13+ messages in thread
From: Daniel Martín @ 2022-07-21 14:51 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Stefan Monnier, emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

>>> I wish this were true, but AFAIK the problem is still very much
>>> present. We deal with it a bit better, but that doesn't mean the
>>> problem is gone. In my tests, editing the end of a 1MB single-line
>>> JSON file is still basically not an option, for example.
>>
>> Please try the feature branch, and you'll see the problem is gone.
>>
>
> The feature has now landed on master.  You can now edit the end of a
> 1GB single-line file as if it were a 1KB file.  Enjoy!
>
> (There are still a few limits, in particular font locking that should
> be turned off in files with long lines.  I will fix them soon.)

Thank you for working on this.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-21 11:50       ` Gregory Heytings
  2022-07-21 12:43         ` Stefan Kangas
  2022-07-21 14:51         ` Daniel Martín
@ 2022-07-21 15:25         ` Stefan Monnier
  2022-07-21 16:09           ` Eli Zaretskii
  2022-07-21 16:36           ` Gregory Heytings
  2022-07-22 14:48         ` Lars Ingebrigtsen
  3 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2022-07-21 15:25 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: emacs-devel

> (There are still a few limits, in particular font locking that should be
>  turned off in files with long lines.  I will fix them soon.)

The font-lock (and `syntax-propertize`) code on `master` should already
"adapt" to long lines, in theory, so if you find single-line large files
significantly worse (because of `font-lock` or `syntax-propertize`) than
non-single line similarly large files, I'd be interested to hear
about it.


        Stefan




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-21 15:25         ` Stefan Monnier
@ 2022-07-21 16:09           ` Eli Zaretskii
  2022-07-21 16:36           ` Gregory Heytings
  1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2022-07-21 16:09 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: gregory, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 21 Jul 2022 11:25:14 -0400
> 
> > (There are still a few limits, in particular font locking that should be
> >  turned off in files with long lines.  I will fix them soon.)
> 
> The font-lock (and `syntax-propertize`) code on `master` should already
> "adapt" to long lines, in theory, so if you find single-line large files
> significantly worse (because of `font-lock` or `syntax-propertize`) than
> non-single line similarly large files, I'd be interested to hear
> about it.

One such recipe is described here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56393#425



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-21 15:25         ` Stefan Monnier
  2022-07-21 16:09           ` Eli Zaretskii
@ 2022-07-21 16:36           ` Gregory Heytings
  1 sibling, 0 replies; 13+ messages in thread
From: Gregory Heytings @ 2022-07-21 16:36 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


>> (There are still a few limits, in particular font locking that should 
>> be turned off in files with long lines.  I will fix them soon.)
>
> The font-lock (and `syntax-propertize`) code on `master` should already 
> "adapt" to long lines, in theory, so if you find single-line large files 
> significantly worse (because of `font-lock` or `syntax-propertize`) than 
> non-single line similarly large files, I'd be interested to hear about 
> it.
>

Take any sufficiently large database dump, minified Javascript file, HTML 
file, etc., edit it with font locking turned on and off, and you'll see 
that font locking still has a very significant impact on performance.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant.
  2022-07-21 11:50       ` Gregory Heytings
                           ` (2 preceding siblings ...)
  2022-07-21 15:25         ` Stefan Monnier
@ 2022-07-22 14:48         ` Lars Ingebrigtsen
  3 siblings, 0 replies; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-22 14:48 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Stefan Monnier, emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

> The feature has now landed on master.  You can now edit the end of a
> 1GB single-line file as if it were a 1KB file.  Enjoy!

Thanks so much for working on this.  I've just tried this briefly (I'm
nominally still on vacation), but it seems to work wonderfully on the
couple pathological files I've tried this on.

The "long line total freezes" in Emacs was one of the most embarrassing
bugs in Emacs, and I'm so pleased that it's finally gone.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-07-22 14:48 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <165817030092.24067.4562191765367761985@vcs2.savannah.gnu.org>
     [not found] ` <20220718185141.39F11C0F203@vcs2.savannah.gnu.org>
2022-07-18 21:01   ` feature/fix-the-long-lines-display-bug c760d2ed16: * etc/PROBLEMS: Remove the entry which is no longer relevant Stefan Monnier
2022-07-18 21:04     ` Gregory Heytings
2022-07-18 21:36       ` Philip Kaludercic
2022-07-18 21:46         ` Gregory Heytings
2022-07-19  4:10           ` Philip Kaludercic
2022-07-19  5:21             ` Gregory Heytings
2022-07-21 11:50       ` Gregory Heytings
2022-07-21 12:43         ` Stefan Kangas
2022-07-21 14:51         ` Daniel Martín
2022-07-21 15:25         ` Stefan Monnier
2022-07-21 16:09           ` Eli Zaretskii
2022-07-21 16:36           ` Gregory Heytings
2022-07-22 14:48         ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).