Re: [O] bug#16832: Emacs goes crazy when deleting lines
Nicolas Goaziou wrote: Eli Zaretskii e...@gnu.org writes: Thanks. So this looks like a problem with Org Mode. In particular, org-element-inline-babel-call-successor takes a lot of time in this case. That function traverses the buffer from top to bottom: (while (search-forward call_ nil t) (save-excursion (goto-char (match-beginning 0)) (when (looking-at org-babel-inline-lob-one-liner-regexp) (throw 'exit (cons 'inline-babel-call (point) This one is an updated function, which doesn't match posted report. I expect it to be faster than the previous implementation. It would be nice to have a new profiler report, though. New test done just now. Still too slow (see video on http://screencast.com/t/elBEfuZtd62), but much, much less... There is an order of magnitude with the previous performance! Excellent. Environment: - GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2014-03-15 on LEG570 - Org-mode version 8.2.5h (release_8.2.5h-808-g60a6c0), fetched 10 mins ago Performance report: --8---cut here---start-8--- - ...2357 97% - ad-activate 2343 97% - ad-activate-advised-definition 2343 97% - ad-make-cache-id2343 97% - ad-arglist 2343 97% - require 2343 97% - apply2343 97% - ad-Advice-require 2343 97% - let2343 97% - let* 2343 97% - org-element-at-point 2342 97% - save-excursion 2342 97% - save-restriction 2342 97% - let 2342 97% - cond 2342 97% - org-element--parse-to 2342 97% - catch 2342 97% - save-excursion2342 97% - save-restriction 2342 97% - let*2342 97% - let* 2017 83% - prog1 2017 83% - catch2017 83% - while 2017 83% - if 2017 83% - progn 2017 83% - setq 2017 83% - org-element--get-next-object-candidates 2017 83% - delq 2017 83% - if2017 83% - mapcar 2017 83% - #lambda 0x1741100e 2017 83% - funcall2017 83% - org-element-latex-or-entity-successor 912 37% - save-excursion912 37% - let 912 37% if 912 37% - org-element-link-successor 389 16% - save-excursion389 16% - let 389 16% if 389 16% - org-element-line-break-successor 215 8% - save-excursion215 8% - let 215 8% and 215 8% - org-element-inline-src-block-successor 99 4% - save-excursion 99 4% if99 4% + org-element-macro-successor 53 2% + org-element-footnote-reference-successor 53
Re: [O] bug#16832: Emacs goes crazy when deleting lines
I thought at using the profiler of Emacs 24, and it gives meaningful results. Good news #2. Here they are: --8---cut here---start-8--- - flyspell-post-command-hook 3271 98% Does this report only cover a single command that took a very long time until it gave you back control (in which case I'm wondering why flyspell-post-command-hook should be called so many times), or does it cover a longer part of your editing session? Stefan
Re: [O] bug#16832: Emacs goes crazy when deleting lines
Stefan wrote: I thought at using the profiler of Emacs 24, and it gives meaningful results. Good news #2. Here they are: --8---cut here---start-8--- - flyspell-post-command-hook 3271 98% Does this report only cover a single command that took a very long time until it gave you back control (in which case I'm wondering why flyspell-post-command-hook should be called so many times), or does it cover a longer part of your editing session? I launched M-x profiler-start just before killing (C-k) the line which I know shows the problem. I launched M-x profiler-report as soon as I got control back. So, it only covers a single command (C-k). Fabrice Niessen -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] bug#16832: Emacs goes crazy when deleting lines
So, it only covers a single command (C-k). Sorry, forget my question: I had forgotten to turn my brain on, somehow (seems to happen too often lately). These numbers aren't call counts, they're just numbers of samples, so there's no evidence that flyspell-post-command-hook was run very many times. Stefan
Re: [O] bug#16832: Emacs goes crazy when deleting lines
From: Fabrice Niessen fni-n...@pirilampo.org Cc: 16...@debbugs.gnu.org, emacs-orgmode emacs-orgmode@gnu.org Date: Fri, 14 Mar 2014 17:00:54 +0100 I realized that Emacs did not into an infloop, but simply gave me back control after a very long time (more than 2 mins). Good news #1. I thought at using the profiler of Emacs 24, and it gives meaningful results. Good news #2. Here they are: --8---cut here---start-8--- - flyspell-post-command-hook 3271 98% - apply 3271 98% - ad-Advice-flyspell-post-command-hook 3271 98% - #compiled 0xe22f273271 98% - byte-code 3271 98% - flyspell-word 3271 98% - org-mode-flyspell-verify 3246 97% - if 3246 97% - let* 3246 97% - prog1 3053 91% - catch3053 91% - while 3053 91% - if 3053 91% - progn 3053 91% - setq 3053 91% - org-element--get-next-object-candidates 3053 91% - delq 3053 91% - if3053 91% - mapcar 3053 91% - #lambda 0x1741100e3053 91% - funcall3053 91% - org-element-inline-babel-call-successor 2873 86% - save-excursion 2873 86% if 2873 86% Thanks. So this looks like a problem with Org Mode. In particular, org-element-inline-babel-call-successor takes a lot of time in this case. That function traverses the buffer from top to bottom: (while (search-forward call_ nil t) (save-excursion (goto-char (match-beginning 0)) (when (looking-at org-babel-inline-lob-one-liner-regexp) (throw 'exit (cons 'inline-babel-call (point) Perhaps this takes too long in such a huge buffer with such long lines. Though, I don't understand yet why Flyspell seems to be a problem in Org mode buffers Clearly, that's because Org functions, in particular org-mode-flyspell-verify, are called from flyspell-post-command-hook: - flyspell-post-command-hook 3271 98% - apply 3271 98% - ad-Advice-flyspell-post-command-hook 3271 98% - #compiled 0xe22f273271 98% - byte-code 3271 98% - flyspell-word 3271 98% - org-mode-flyspell-verify 3246 97% If org-mode-flyspell-verify is expensive, it is not a good idea to use it as flyspell-generic-check-word-predicate in huge Org buffers, since Flyspell will invoke it after each command. I hope Org developers will respond. Or maybe you should simply submit this bug report to Org bug tracker/list.
Re: [O] bug#16832: Emacs goes crazy when deleting lines
Hello, Eli Zaretskii e...@gnu.org writes: Thanks. So this looks like a problem with Org Mode. In particular, org-element-inline-babel-call-successor takes a lot of time in this case. That function traverses the buffer from top to bottom: (while (search-forward call_ nil t) (save-excursion (goto-char (match-beginning 0)) (when (looking-at org-babel-inline-lob-one-liner-regexp) (throw 'exit (cons 'inline-babel-call (point) This one is an updated function, which doesn't match posted report. I expect it to be faster than the previous implementation. It would be nice to have a new profiler report, though. Regards, -- Nicolas Goaziou
Re: [O] bug#16832: Emacs goes crazy when deleting lines
From: Nicolas Goaziou n.goaz...@gmail.com Cc: Fabrice Niessen fni-n...@pirilampo.org, emacs-orgmode@gnu.org, 16...@debbugs.gnu.org Date: Sat, 15 Mar 2014 17:17:26 +0100 (while (search-forward call_ nil t) (save-excursion (goto-char (match-beginning 0)) (when (looking-at org-babel-inline-lob-one-liner-regexp) (throw 'exit (cons 'inline-babel-call (point) This one is an updated function, which doesn't match posted report. Do you happen to know, or can measure, how much faster is the latest version? Given the timing provided by the OP, it'd have to be at least 100 times faster, to avoid annoying delays after each command.
Re: [O] bug#16832: Emacs goes crazy when deleting lines
Eli Zaretskii e...@gnu.org writes: Do you happen to know, or can measure, how much faster is the latest version? Given the timing provided by the OP, it'd have to be at least 100 times faster, to avoid annoying delays after each command. Basically it is, (search-forward call_) versus (re-search-forward \\([^\n]*?\\)call_\\([^()[:space:]\n]+?\\)\\(\\[\\(.*?\\)\\]\\|\\(\\)\\)(\\(.*?\\))\\(\\[\\(.*?\\)\\]\\)?) Of course, the speed factor depends on the length of the lines in the document, but it could make a significant difference for the OP. Regards, -- Nicolas Goaziou
Re: [O] bug#16832: Emacs goes crazy when deleting lines
Eli Zaretskii wrote: From: Fabrice Niessen fni-n...@pirilampo.org Cc: 16...@debbugs.gnu.org Date: Wed, 26 Feb 2014 20:42:20 +0100 Eli Zaretskii wrote: From: Fabrice Niessen fni-n...@pirilampo.org Cc: 16...@debbugs.gnu.org Date: Wed, 26 Feb 2014 12:06:24 +0100 Then try F12 (if you are on XP), or try attaching a debugger and getting a C and Lisp backtrace. Hope this helps: Thanks. Without a Lisp-level backtrace, there's not enough useful info here. Is there something I can do to get it in such a debugger session? Probably, but I don't know what to suggest. I don't understand the error messages that you get from GDB, this usually happens when one tries to attach a debugger to a program that is already being debugged, which seems to be not the case here. Weird. Perhaps finding the minimal set of customizations that reproduces the issue would lead faster to the solution. So you mean that the backtrace, with saveplace calls, does not lead to him as the culprit? These are not saveplace calls, this is Emacs searching for a string that includes saveplace.elc and save-place-alist as substrings. I made a big progress on this one. I realized that Emacs did not into an infloop, but simply gave me back control after a very long time (more than 2 mins). Good news #1. I thought at using the profiler of Emacs 24, and it gives meaningful results. Good news #2. Here they are: --8---cut here---start-8--- - flyspell-post-command-hook 3271 98% - apply 3271 98% - ad-Advice-flyspell-post-command-hook 3271 98% - #compiled 0xe22f273271 98% - byte-code 3271 98% - flyspell-word 3271 98% - org-mode-flyspell-verify 3246 97% - if 3246 97% - let* 3246 97% - prog1 3053 91% - catch3053 91% - while 3053 91% - if 3053 91% - progn 3053 91% - setq 3053 91% - org-element--get-next-object-candidates 3053 91% - delq 3053 91% - if3053 91% - mapcar 3053 91% - #lambda 0x1741100e3053 91% - funcall3053 91% - org-element-inline-babel-call-successor 2873 86% - save-excursion 2873 86% if 2873 86% + org-element-latex-or-entity-successor 81 2% + org-element-link-successor 35 1% + org-element-line-break-successor19 0% + org-element-inline-src-block-successor 9 0% + org-element-footnote-reference-successor 5 0% + org-element-macro-successor 5 0% + org-element-statistics-cookie-successor 5 0% + org-element-timestamp-successor 5 0% + org-element-export-snippet-successor 4 0% + org-element-radio-target-successor 4 0% + org-element-target-successor 4 0% + org-element-sub/superscript-successor3 0% + org-element-text-markup-successor1 0% + org-element-at-point 193 5% + flyspell-word-search-forward 15 0% + redisplay_internal (C function) 28 0% + ... 27 0% --8---cut here---end---8--- Though, I don't understand yet why Flyspell seems to be a problem in Org mode buffers, and not in Text mode buffers: as you can see in the video on http://screencast.com/t/UiihFfPk, 1. Text mode + all my config (enabling Flyspell by default) is OK, (from 0:07 to 0:14, then undoing the changes) 2. Org mode + all my config (enabling Flyspell by
