--- Begin Message ---
|
Subject: |
[Bug] 24.3.50; massive slow down in forward-line |
|
Date: |
Fri, 21 Feb 2014 13:16:07 +0100 |
|
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#16830: [Bug] 24.3.50; massive slow down in forward-line |
|
Date: |
Sun, 22 Jun 2014 19:50:52 +0300 |
> Date: Mon, 17 Mar 2014 18:39:33 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
>
> > Date: Mon, 17 Mar 2014 19:05:27 +0400
> > From: Dmitry Antipov <address@hidden>
> > CC: address@hidden
> >
> > 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.
--- End Message ---