GNU bug report logs - #27622
Trying to improve the speed of linum-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27622 in the body.
You can then email your comments to 27622 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fis Trivial <ybbs.daans <at> hotmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Trying to improve the speed of linum-mode
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:




--- 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?

Message #8 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fis Trivial <ybbs.daans <at> hotmail.com>
Cc: 27622 <at> debbugs.gnu.org
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sat, 08 Jul 2017 20:01:09 +0300

> From: Fis Trivial <ybbs.daans <at> 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.

Message #11 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fis Trivial <ybbs.daans <at> hotmail.com>
Cc: 27622 <at> debbugs.gnu.org
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sat, 08 Jul 2017 21:55:20 +0300

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

> From: Fis Trivial <ybbs.daans <at> 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.

Message #14 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fis Trivial <ybbs.daans <at> hotmail.com>
Cc: 27622 <at> debbugs.gnu.org
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sat, 08 Jul 2017 22:44:10 +0300

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

> From: Fis Trivial <ybbs.daans <at> 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.

Message #17 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fis Trivial <ybbs.daans <at> hotmail.com>
Cc: 27622 <at> debbugs.gnu.org
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sun, 09 Jul 2017 17:39:49 +0300

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

Message #20 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Fis Trivial <ybbs.daans <at> hotmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "27622 <at> debbugs.gnu.org" <27622 <at> debbugs.gnu.org>
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sun, 9 Jul 2017 18:06:18 +0000

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

Message #25 received at 27622-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Fis Trivial <ybbs.daans <at> hotmail.com>
Cc: 27622-done <at> debbugs.gnu.org
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sun, 09 Jul 2017 21:27:25 +0300

> From: Fis Trivial <ybbs.daans <at> hotmail.com>
> CC: "27622 <at> debbugs.gnu.org" <27622 <at> 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.

Message #28 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27622 <at> debbugs.gnu.org, Fis Trivial <ybbs.daans <at> hotmail.com>
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Sun, 09 Jul 2017 19:29:11 -0400

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

Message #31 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 27622 <at> debbugs.gnu.org, ybbs.daans <at> hotmail.com
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Mon, 10 Jul 2017 19:50:02 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Fis Trivial <ybbs.daans <at> hotmail.com>,  27622 <at> 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"?

Message #34 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27622 <at> debbugs.gnu.org, ybbs.daans <at> hotmail.com
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
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.

Message #37 received at 27622 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 27622 <at> debbugs.gnu.org, ybbs.daans <at> hotmail.com
Subject: Re: bug#27622: Trying to improve the speed of linum-mode
Date: Mon, 31 Jul 2017 06:11:23 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: ybbs.daans <at> hotmail.com,  27622 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.