[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.