* bug#16832: Emacs goes crazy when deleting lines [not found] ` <86d2igl9x3.fsf-oHC15RC7JGTNLxjTenLetw@public.gmane.org> @ 2014-03-14 16:00 ` Fabrice Niessen 2014-03-15 15:47 ` Eli Zaretskii 2014-03-17 14:57 ` Stefan 0 siblings, 2 replies; 9+ messages in thread From: Fabrice Niessen @ 2014-03-14 16:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-orgmode, 16832-ubl+/3LiMTaZdePnXv/OxA Eli Zaretskii wrote: >> From: "Fabrice Niessen" <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org> >> Cc: 16832-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org >> Date: Wed, 26 Feb 2014 20:42:20 +0100 >> >> Eli Zaretskii wrote: >> >> From: "Fabrice Niessen" <fni-news-TA4HMoP+1wHrZ44/DZwexQ@public.gmane.org> >> >> Cc: 16832-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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 0xe22f27> 3271 98% - byte-code 3271 98% - flyspell-word 3271 98% - org-mode-flyspell-verify 3246 97% - if 3246 97% - let* 3246 97% - prog1 3053 91% - catch 3053 91% - while 3053 91% - if 3053 91% - progn 3053 91% - setq 3053 91% - org-element--get-next-object-candidates 3053 91% - delq 3053 91% - if 3053 91% - mapcar 3053 91% - #<lambda 0x1741100e> 3053 91% - funcall 3053 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-successor 19 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-successor 3 0% + org-element-text-markup-successor 1 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 default) is NOT OK. (from 0:40, blocking at 0:49, giving control back at 3:15) Best regards, Fabrice PS- Org-mode version 8.2.5h (release_8.2.5h-733-gd55438) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#16832: Emacs goes crazy when deleting lines 2014-03-14 16:00 ` bug#16832: Emacs goes crazy when deleting lines Fabrice Niessen @ 2014-03-15 15:47 ` Eli Zaretskii 2014-03-15 16:17 ` Nicolas Goaziou 2014-03-17 14:57 ` Stefan 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2014-03-15 15:47 UTC (permalink / raw) To: Fabrice Niessen; +Cc: emacs-orgmode, 16832 > From: Fabrice Niessen <fni-news@pirilampo.org> > Cc: 16832@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 0xe22f27> 3271 98% > - byte-code 3271 98% > - flyspell-word 3271 98% > - org-mode-flyspell-verify 3246 97% > - if 3246 97% > - let* 3246 97% > - prog1 3053 91% > - catch 3053 91% > - while 3053 91% > - if 3053 91% > - progn 3053 91% > - setq 3053 91% > - org-element--get-next-object-candidates 3053 91% > - delq 3053 91% > - if 3053 91% > - mapcar 3053 91% > - #<lambda 0x1741100e> 3053 91% > - funcall 3053 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 0xe22f27> 3271 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#16832: Emacs goes crazy when deleting lines 2014-03-15 15:47 ` Eli Zaretskii @ 2014-03-15 16:17 ` Nicolas Goaziou 2014-03-15 17:36 ` Eli Zaretskii [not found] ` <87ob17sag9.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 2 replies; 9+ messages in thread From: Nicolas Goaziou @ 2014-03-15 16:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Fabrice Niessen, emacs-orgmode, 16832 Hello, Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#16832: Emacs goes crazy when deleting lines 2014-03-15 16:17 ` Nicolas Goaziou @ 2014-03-15 17:36 ` Eli Zaretskii 2014-03-15 17:57 ` Nicolas Goaziou [not found] ` <87ob17sag9.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2014-03-15 17:36 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: fni-news, emacs-orgmode, 16832 > From: Nicolas Goaziou <n.goaziou@gmail.com> > Cc: Fabrice Niessen <fni-news@pirilampo.org>, emacs-orgmode@gnu.org, 16832@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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#16832: Emacs goes crazy when deleting lines 2014-03-15 17:36 ` Eli Zaretskii @ 2014-03-15 17:57 ` Nicolas Goaziou 0 siblings, 0 replies; 9+ messages in thread From: Nicolas Goaziou @ 2014-03-15 17:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: fni-news, emacs-orgmode, 16832 Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <87ob17sag9.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: bug#16832: Emacs goes crazy when deleting lines [not found] ` <87ob17sag9.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2014-03-20 11:33 ` Fabrice Niessen 0 siblings, 0 replies; 9+ messages in thread From: Fabrice Niessen @ 2014-03-20 11:33 UTC (permalink / raw) To: Nicolas Goaziou Cc: Eli Zaretskii, emacs-orgmode-mXXj517/zsQ, 16832-ubl+/3LiMTaZdePnXv/OxA Nicolas Goaziou wrote: > Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.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-id 2343 97% - ad-arglist 2343 97% - require 2343 97% - apply 2343 97% - ad-Advice-require 2343 97% - let 2343 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-excursion 2342 97% - save-restriction 2342 97% - let* 2342 97% - let* 2017 83% - prog1 2017 83% - catch 2017 83% - while 2017 83% - if 2017 83% - progn 2017 83% - setq 2017 83% - org-element--get-next-object-candidates 2017 83% - delq 2017 83% - if 2017 83% - mapcar 2017 83% - #<lambda 0x1741100e> 2017 83% - funcall 2017 83% - org-element-latex-or-entity-successor 912 37% - save-excursion 912 37% - let 912 37% if 912 37% - org-element-link-successor 389 16% - save-excursion 389 16% - let 389 16% if 389 16% - org-element-line-break-successor 215 8% - save-excursion 215 8% - let 215 8% and 215 8% - org-element-inline-src-block-successor 99 4% - save-excursion 99 4% if 99 4% + org-element-macro-successor 53 2% + org-element-footnote-reference-successor 53 2% + org-element-statistics-cookie-successor 53 2% + org-element-timestamp-successor 51 2% + org-element-target-successor 50 2% + org-element-radio-target-successor 49 2% + org-element-export-snippet-successor 47 1% + org-element-sub/superscript-successor 37 1% + org-element-text-markup-successor 8 0% intern 1 0% + let 325 13% + cond 1 0% Automatic GC 14 0% + flyspell-post-command-hook 28 1% + command-execute 17 0% + redisplay_internal (C function) 12 0% --8<---------------cut here---------------end--------------->8--- Best regards, Fabrice -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#16832: Emacs goes crazy when deleting lines 2014-03-14 16:00 ` bug#16832: Emacs goes crazy when deleting lines Fabrice Niessen 2014-03-15 15:47 ` Eli Zaretskii @ 2014-03-17 14:57 ` Stefan [not found] ` <jwvsiqg6fn6.fsf-monnier+emacsbugs-mXXj517/zsQ@public.gmane.org> 1 sibling, 1 reply; 9+ messages in thread From: Stefan @ 2014-03-17 14:57 UTC (permalink / raw) To: Fabrice Niessen; +Cc: Eli Zaretskii, emacs-orgmode, 16832 > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <jwvsiqg6fn6.fsf-monnier+emacsbugs-mXXj517/zsQ@public.gmane.org>]
* bug#16832: Emacs goes crazy when deleting lines [not found] ` <jwvsiqg6fn6.fsf-monnier+emacsbugs-mXXj517/zsQ@public.gmane.org> @ 2014-03-17 21:29 ` Fabrice Niessen 2014-03-17 23:28 ` Stefan 0 siblings, 1 reply; 9+ messages in thread From: Fabrice Niessen @ 2014-03-17 21:29 UTC (permalink / raw) To: Stefan; +Cc: emacs-orgmode, 16832-ubl+/3LiMTaZdePnXv/OxA 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bug#16832: Emacs goes crazy when deleting lines 2014-03-17 21:29 ` Fabrice Niessen @ 2014-03-17 23:28 ` Stefan 0 siblings, 0 replies; 9+ messages in thread From: Stefan @ 2014-03-17 23:28 UTC (permalink / raw) To: Fabrice Niessen; +Cc: Eli Zaretskii, emacs-orgmode, 16832 > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-03-20 11:33 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <86d2igl9x3.fsf@somewhere.org>
[not found] ` <mailman.15712.1393002495.10748.bug-gnu-emacs@gnu.org>
[not found] ` <861tys93qy.fsf@somewhere.org>
[not found] ` <mailman.15925.1393259354.10748.bug-gnu-emacs@gnu.org>
[not found] ` <86eh2r4ipj.fsf@somewhere.org>
[not found] ` <mailman.16008.1393345635.10748.bug-gnu-emacs@gnu.org>
[not found] ` <86bnxugmkv.fsf@somewhere.org>
[not found] ` <83txbly9xq.fsf@gnu.org>
[not found] ` <86y50xirtv.fsf@somewhere.org>
[not found] ` <mailman.16142.1393444275.10748.bug-gnu-emacs@gnu.org>
[not found] ` <86d2igl9x3.fsf-oHC15RC7JGTNLxjTenLetw@public.gmane.org>
2014-03-14 16:00 ` bug#16832: Emacs goes crazy when deleting lines Fabrice Niessen
2014-03-15 15:47 ` Eli Zaretskii
2014-03-15 16:17 ` Nicolas Goaziou
2014-03-15 17:36 ` Eli Zaretskii
2014-03-15 17:57 ` Nicolas Goaziou
[not found] ` <87ob17sag9.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-20 11:33 ` Fabrice Niessen
2014-03-17 14:57 ` Stefan
[not found] ` <jwvsiqg6fn6.fsf-monnier+emacsbugs-mXXj517/zsQ@public.gmane.org>
2014-03-17 21:29 ` Fabrice Niessen
2014-03-17 23:28 ` Stefan
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).