emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* 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

* 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

* 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

* 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

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