emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Grant Rettke <gcr@wisdomandwonder.com>
To: Nick Dokos <ndokos@gmail.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: long code blocks making Org Mode very slow
Date: Wed, 22 Jul 2015 18:09:22 -0500	[thread overview]
Message-ID: <CAAjq1mezFsjUjRuE5DMv2vG7wjjDfjFQGVH4XTWUaX6R1jPsjg@mail.gmail.com> (raw)
In-Reply-To: <87mvyomkjw.fsf@pierrot.dokosmarshall.org>

I will play around with it. I didn't try to do a ECM.

Playing around with it tonight starting with

open /Applications/Emacs.app --new --args -Q

So using 8.2.10.

Sometimes I can get a slow down when calling `next-line' repeatedly.

I will play around with it and report if I get something reproducible
and an ECM.
Grant Rettke
--
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
“All creativity is an extended form of a joke.” --Kay
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Wed, Jul 22, 2015 at 7:41 AM, Nick Dokos <ndokos@gmail.com> wrote:
> Angus M <anguscmelville@gmail.com> writes:
>
>>> When I have the cursor inside of the code block for the code, moving
>>> up or done one line or one page takes 2-3 seconds.
>>> Grant Rettke
>>> --
>>
>> Thanks for confirming that you also experience the slow-down.
>>
>> I think that the only way to remedy this is to modify the
>> 'org-src-font-lock-fontify-block' function in org-src.el to allow
>> just-in-time fontification, (rather than the current complete
>> re-fontification of the whole code block upon any changes).
>>
>
> I'm not convinced that this is the reason. I tried with a simple file
> (a headline, some text, a source code block with 7K lines of python -
> the decimal.py file from the standard python library - and some more
> text).
>
> I set org-src-fontify-natively to nil (through a local variable in
> the file). Adding text after the code block was OK but adding text
> before the code block was very slow. If fontification were the problem,
> I'd expect both to be fast.
>
> I did a profile with elp and it seems to me that the problem is footnote
> detection:
>
> --8<---------------cut here---------------start------------->8---
> org-activate-footnote-links                                   7           13.397064245  1.9138663207
> org-footnote-next-reference-or-definition                     7           13.396982566  1.9138546524
> org-footnote-in-valid-context-p                               378         13.384084804  0.0354076317
> org-in-block-p                                                322         13.146482877  0.0408275865
> org-between-regexps-p                                         2576        12.544080215  0.0048695963
> org-footnote-at-reference-p                                   189         6.7601071689  0.0357677627
> org-footnote-at-definition-p                                  189         6.6263815400  0.0350602197
> org-element--parse-to                                         15          0.41858634    0.027905756
> org-element--cache-sync                                       18          0.3965463360  0.0220303520
> org-fontify-meta-lines-and-blocks                             14          0.3946110120  0.0281865008
> org-fontify-meta-lines-and-blocks-1                           14          0.3944775729  0.0281769695
> org-element--current-element                                  7           0.3642047120  0.0520292445
> ...
> --8<---------------cut here---------------end--------------->8---
>
> I didn't check how org-between-regexps-p and org-footnote-at-*-p are
> related, but those three seem to account for the lion's share of the
> time.
>
> BTW, org-src-font-lock-fontify-block calls font-lock-fontify-buffer
> which is not supposed to be called from lisp programs: the doc string
> suggests using font-lock-ensure or font-lock-flush. I tried the first
> but it did not make any difference in the speed. But I guess it should
> be changed.
>
> --
> Nick
>
>

      reply	other threads:[~2015-07-22 23:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-14 18:15 long code blocks making Org Mode very slow Angus M
2015-07-14 19:41 ` Sebastien Vauban
2015-07-14 21:06   ` Angus M
2015-07-14 21:44 ` Nick Dokos
2015-07-14 23:39   ` Angus M
2015-07-15 12:22 ` Angus M
2015-07-17  1:10   ` Grant Rettke
2015-07-21 11:09     ` Angus M
2015-07-22  1:20       ` Grant Rettke
2015-07-22 10:09         ` Angus M
2015-07-22 12:41           ` Nick Dokos
2015-07-22 23:09             ` Grant Rettke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAjq1mezFsjUjRuE5DMv2vG7wjjDfjFQGVH4XTWUaX6R1jPsjg@mail.gmail.com \
    --to=gcr@wisdomandwonder.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ndokos@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).