bug#27622: Trying to improve the speed of linum-mode

bug#27622: Trying to improve the speed of linum-mode

[Fis Trivial]

For some reasons, the linum-mode needs to go over the whole buffer in
order to update the line numbers. It's ok when viewing a small buffer,
but when comes to something large it will slow the emacs down like I
was viewing a ppt(try kernel patch). I don't really understand the
code, but I changed it a little bit and it works fine so far. Here is
the patch, linum-o.el is the original code:




--- linum-o.el	2017-06-06 09:04:32.012568000 +0800
+++ linum.el	2017-07-
08 16:45:45.710518928 +0800
@@ -174,7 +174,7 @@
         (fmt (cond
((stringp linum-format) linum-format)
                    ((eq linum-
format 'dynamic)
                     (let ((w (length (number-to-string

-                                      (count-lines (point-min) (point-
max))))))
+                                      (count-lines (window-
start win) (window-end win t))))))
                       (concat "%"
(number-to-string w) "d")))))
         (width 0))
     (run-hooks 'linum-
before-numbering-hook)




The minor change replaced (point-min/max) to (window-start/end) which
saves a lots of iterations and did improve the speed at start-up. but
if I move the cursor to the end of the buffer, it slows down again and
I don't know why it's happening.
So, I got wonder is there any particular reason to use (point-min)
instead of (window-start)? And what's the cause of slowing down when I
move the cursor to the end of buffer?

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

> From: Fis Trivial <ybbs.daans@hotmail.com>
> Date: Sat, 8 Jul 2017 09:25:38 +0000
> 
> For some reasons, the linum-mode needs to go over the whole buffer in
> order to update the line numbers. It's ok when viewing a small buffer,
> but when comes to something large it will slow the emacs down like I
> was viewing a ppt(try kernel patch). I don't really understand the
> code, but I changed it a little bit and it works fine so far. Here is
> the patch, linum-o.el is the original code:

Thanks.

Recently, the development sources were updated to provide line-number
display built into Emacs.  That facility doesn't count lines in the
whole buffer, so the slow-down you mention doesn't happen.

So I see no reason to try to fix this issue in linum-mode.

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> From: Fis Trivial <ybbs.daans@hotmail.com>
> Date: Sat, 8 Jul 2017 17:16:45 +0000
> 
> Thanks for the reply.
> I have compiled the latest code from master branch and tried
> the new line number mode. The new line number mode has exactly the same 
> effect
> as the patched linum.el.  When opening a large file, it runs smooth at 
> the beginning
> of the buffer but slows down as the cursor closing to the end of the 
> buffer.

Please show a file where it happens to you.  Please also tell which
variables elated to line-number display you customized and how.

I tried this with a 33000-line buffer, and didn't see the problem you
describe.  So maybe only some files trigger the problem.

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> From: Fis Trivial <ybbs.daans@hotmail.com>
> Date: Sat, 8 Jul 2017 19:22:06 +0000
> 
> Linux kernel patch-4.12. It's a file with 2040936 lines.

Where can I download it?

> Also in most of 
> the time I need to look at some formatted data files which could easily 
> be larger than the kernel patch.
> 
> 
> There is only one line of the code related to the new line number mode:
> 
> (setq display-line-numbers t)
> 
> According to the description in NEWS, it should activate the new line 
> number mode, but it doesn't.

It activates that in the buffer where this is executed, which is not
what you want.

> So after opening the file, I use the 
> command M-x toggle-display-line-numbers to activate the new line number 
> mode. After that, it should run smoothly if I am only viewing the upper 
> portion of the buffer. But if I use "C-x ]" to move the cursor to the 
> end of the buffer then Emacs will slow down dramatically.

I need to play with the file to see what's going on.

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

[Please use "reply-to-all" command in your mailer, so that the bug
tracker gets a copy of your messages.]

> From: Fis Trivial <ybbs.daans@hotmail.com>
> Date: Sat, 8 Jul 2017 19:57:26 +0000
> 
> https://www.kernel.org/
> After opening the page, click the [patch] in a line looks like the 
> following:
> mainline: 4.12 2017-07-02 [tarball] [pgp] [patch]            [view diff] 
> [browse]

Thanks.  I sped up the line-number display in some popular use cases,
please see if that solves your problem.

bug#27622: Trying to improve the speed of linum-mode

[Fis Trivial]

It's great. Now the Emacs works perfectly. Thanks for your work.

On 07/09/2017 10:39 PM, Eli Zaretskii wrote:
> [Please use "reply-to-all" command in your mailer, so that the bug
> tracker gets a copy of your messages.]
>
>> From: Fis Trivial <ybbs.daans@hotmail.com>
>> Date: Sat, 8 Jul 2017 19:57:26 +0000
>>
>> https://www.kernel.org/
>> After opening the page, click the [patch] in a line looks like the
>> following:
>> mainline: 4.12 2017-07-02 [tarball] [pgp] [patch]            [view diff]
>> [browse]
> Thanks.  I sped up the line-number display in some popular use cases,
> please see if that solves your problem.

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

> From: Fis Trivial <ybbs.daans@hotmail.com>
> CC: "27622@debbugs.gnu.org" <27622@debbugs.gnu.org>
> Date: Sun, 9 Jul 2017 18:06:18 +0000
> 
> It's great. Now the Emacs works perfectly. Thanks for your work.

Thanks, closing.

bug#27622: Trying to improve the speed of linum-mode

[Glenn Morris]

Time to obsolete linum.el (which now has two replacements)?

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Fis Trivial <ybbs.daans@hotmail.com>,  27622@debbugs.gnu.org
> Date: Sun, 09 Jul 2017 19:29:11 -0400
> 
> 
> Time to obsolete linum.el (which now has two replacements)?

Probably.  But do we move it to obsolete right away, or just mark its
main entry "obsolete"?

bug#27622: Trying to improve the speed of linum-mode

[Glenn Morris]

Eli Zaretskii wrote:

>> Time to obsolete linum.el (which now has two replacements)?
>
> Probably.  But do we move it to obsolete right away, or just mark its
> main entry "obsolete"?

I would move it to obsolete, but add a manual autoload so that M-x
linum-mode still works. Cf iswitchb-mode in icomplete.el.

bug#27622: Trying to improve the speed of linum-mode

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: ybbs.daans@hotmail.com,  27622@debbugs.gnu.org
> Date: Sun, 30 Jul 2017 22:06:31 -0400
> 
> Eli Zaretskii wrote:
> 
> >> Time to obsolete linum.el (which now has two replacements)?
> >
> > Probably.  But do we move it to obsolete right away, or just mark its
> > main entry "obsolete"?
> 
> I would move it to obsolete, but add a manual autoload so that M-x
> linum-mode still works. Cf iswitchb-mode in icomplete.el.

Fine with me, thanks.