help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why emacs rendering is slow when encountering long lines?


From: Eli Zaretskii
Subject: Re: Why emacs rendering is slow when encountering long lines?
Date: Mon, 21 Oct 2013 06:00:52 +0300

> Date: Sun, 20 Oct 2013 19:08:51 -0700 (PDT)
> From: Jiaxin Cao <jiaxin.cao@gmail.com>
> Injection-Date: Mon, 21 Oct 2013 02:08:52 +0000
> 
> Let me provide more information about this. To reproduce the scenario, just 
> create a line containing about 450 chars, and copy the line 10000 times.

What characters?  It's important.

Also, if you add an empty line here and there, do things improve?

> I use the text-mode to test this buffer. Scroll-down means the cursor goes 
> up. My OS is windows 8. Emacs version is 24.3.1.

In that case, indeed scroll-down is expected to be slower than
scroll-up.  The technical reasons, in a nutshell, is that Emacs needs
to find where to start the display of the next screenful, and that is
harder when you go backwards in the buffer.

> I think this is not the problem of the rendering engine. You can do some 
> tests like this. 
> (defun test-redraw-display ()
>   (interactive)
>   (message (format-time-string "%Y-%m-%dT%T:%6N"))
>   (redraw-display)
>   (message (format-time-string "%Y-%m-%dT%T:%6N")))
> 
> (defun test-scroll-down ()
>   (interactive)
>   (message (format-time-string "%Y-%m-%dT%T:%6N"))
>   (scroll-down)
>   (message (format-time-string "%Y-%m-%dT%T:%6N")))
> 
> (defun test-scroll-up ()
>   (interactive)
>   (message (format-time-string "%Y-%m-%dT%T:%6N"))
>   (scroll-up)
>   (message (format-time-string "%Y-%m-%dT%T:%6N")))
> 
> Here is the test results on the buffer mentioned above.
> |-------------------------+----------------+-------------+-----------|
> |                         | redraw-display | scroll-down | scroll-up |
> |-------------------------+----------------+-------------+-----------|
> | Truncate-lines enabled  | < 1ms          | 82ms        | 47ms      |
> | Truncate-lines disabled | < 1ms          | 76ms        | 54ms      |
> |-------------------------+----------------+-------------+-----------|
> 
> Based on the results, I guess the scroll-down is the bottleneck of the 
> scrolling performance.

Your conclusion is wrong.  You assume that scroll-down is just that,
but it isn't.  It invokes the display engine to know where to start
the next/previous screenful.  Try to think of an algorithm to
determine that, when the buffer might have different fonts, and I
think you will see why.

> I know scroll-down is a little complicated to implement, but if you  do the 
> same thing in notepad, you'll find notepad is way smoother than emacs in term 
> of scrolling.

Emacs gives you a plethora of display features that Notepad can only
dream of.  Start with the fact that Emacs needs to support
variable-size fonts in the same buffer and even on the same line.
That complicates matters quite a lot.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]