Subject: bug#16830: closed (Re: bug#16830: [Bug] 24.3.50; massive slow down in forward-line)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 22 Jun 2014 16:52:02 +0000

Your bug report

#16830: [Bug] 24.3.50; massive slow down in forward-line

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
16830: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16830
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#16830: [Bug] 24.3.50; massive slow down in forward-line
From: Eli Zaretskii <[email-masked]>
To: [email-masked]
Date: Sun, 22 Jun 2014 19:50:52 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> Date: Mon, 17 Mar 2014 18:39:33 +0200
> From: Eli Zaretskii <[email-masked]>
> Cc: [email-masked]
> 
> > Date: Mon, 17 Mar 2014 19:05:27 +0400
> > From: Dmitry Antipov <[email-masked]>
> > CC: [email-masked]
> > 
> > On 03/10/2014 10:58 PM, Eli Zaretskii wrote:
> > 
> > > It would be nice to be able to turn the cache on and off dynamically,
> > > depending on the actual line length of the buffer.  I tried to
> > > implement this, but my naive implementation didn't work well, because
> > > sampling of the lines tends to be extremely un-representative.  If
> > > someone can come up with a smarter implementation, please show it.
> > 
> > What if we just maintain the '\n' counter per each buffer text?
> 
> How would you know how many newlines are there in the buffer?
> Counting them is an overhead in itself that we currently avoid (see
> line-number-display-limit).
> 
> But anyway, feel free to implement something and test it.  As I've
> written above, I tried (for admittedly short time), but didn't get
> good results.

No further comments, so I'm closing this bug, as I see no further
place for improving the performance of the cache.

Subject: [Bug] 24.3.50; massive slow down in forward-line
From: "Stefan-W. Hahn" <[email-masked]>
To: [email-masked]
Date: Fri, 21 Feb 2014 13:16:07 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Good day,

I have measured a massive slow down for emacs24 on windows. I struggled
while using org-mode columnview, which takes for a short table several
minutes compared to a second with an older versino of emacs.

I tried to dig it down:

Running on an Core I7 Laptop with Windows 7/64 bit,
starting "emacs -q"

I got the  following times (elp measurement) for the org-mode function
org-goto-line:

Emacs 24.3.1 is ok, on Emacs 24.3.50 (I tested
https://www.dropbox.com/sh/3pgcb3iiy8s9irl/77pwM1O-5K/emacs-20140217-r116465-bin-i386.zip
) got a slow down of factor 10!!

org-goto-line (24.3.1)
test-org-goto-line  1           0.2           0.2
forward-line        10000       0.0640000000  6.40...e-006
widen               10000       0.003         3e-007
goto-char           10001       0.002         1.99...e-007

org-forward-line with narrow (24.3.1)
test-forward-line  1           0.042         0.042
forward-line       10000       0.003         3e-007
goto-char          1           0.0           0.0

org-forward-line without narrow (24.3.1)
test-forward-line  1           0.046         0.046
forward-line       10000       0.007         7e-007
goto-char          1           0.0           0.0

org-goto-line (24.3.50.1)
test-org-goto-line  1           2.141         2.141
forward-line        10000       1.8479999999  0.0001847999
goto-char           10001       0.006         5.99...e-007
widen               10000       0.005         5e-007

org-forward-line with narrow (24.3.50.1)
test-forward-line  1           0.102         0.102
forward-line       10000       0.0160000000  1.60...e-006
goto-char          1           0.0           0.0

org-forward-line without narrow (24.3.50.1)
test-forward-line  1           0.125         0.125
forward-line       10000       0.005         5e-007
goto-char          1           0.0           0.0

Problem seemss to be forward-line.

Tested with following test case:

#+BEGIN_SRC elisp
(defsubst my-org-goto-line (N)
  (save-restriction
    (widen)
    (goto-char (point-min))
    (forward-line (1- N))))

(defun test-org-goto-line ()
  (with-temp-buffer
    (open-line 10000)
    (goto-char (point-min))
    (narrow-to-region (point-min) (point-max))
    (dotimes (i 10000)
      (my-org-goto-line i)
      )
    )
  )

(defun test-forward-line (with-narrow)
  (with-temp-buffer
    (open-line 10000)
    (goto-char (point-min))
    (if with-narrow
        (narrow-to-region (point-min) (point-max)))
    (dotimes (i 10000)
      (forward-line 1)
      )
    )
  )

(defvar test-buffer nil)
(defun test-performance/org-goto-line ()
  (interactive)
  (elp-instrument-list '(test-org-goto-line forward-line goto-char widen))
  (test-org-goto-line)
  (let ((elp-recycle-buffers-p nil)
        rc)
    (elp-results)
    (setq rc (buffer-string))
    (kill-buffer)
    (with-current-buffer test-buffer
      (insert "org-goto-line ("
              emacs-version
              ")\n")
      (insert rc "\n"))
    )
  (elp-restore-all)
)

(defun test-performance/forward-line (with-narrow)
  (interactive)
  (elp-instrument-list '(test-forward-line forward-line goto-char widen))
  (test-forward-line with-narrow)
  (let ((elp-recycle-buffers-p nil)
        rc)
    (elp-results)
    (setq rc (buffer-string))
    (kill-buffer)
    (with-current-buffer test-buffer
      (insert (format "org-forward-line %s (" (if with-narrow "with narrow" "without narrow"))
              emacs-version
              ")\n")
      (insert rc "\n")))
  (elp-restore-all)
)

(defun test-performance ()
  (interactive)
  (setq test-buffer (generate-new-buffer "*Performance*"))
  (test-performance/org-goto-line)
  (test-performance/forward-line t)
  (test-performance/forward-line nil)
  (pop-to-buffer test-buffer))
#+END:

With kind regards,
Stefan

-- 
Stefan-W. Hahn                          It is easy to make things.
                                        It is hard to make things simple.