emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] footnote fontify causing massive slowdown


From: Aaron Ecay
Subject: Re: [O] footnote fontify causing massive slowdown
Date: Sat, 05 Dec 2015 15:55:48 +0000
User-agent: Notmuch/0.20.2+65~gbd5504e (http://notmuchmail.org) Emacs/25.0.50.1 (x86_64-unknown-linux-gnu)

Hi Nicolas,

2015ko abenudak 5an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <address@hidden> writes:
> 
>> Indeed.  However, this code was needlessly slow because it failed to
>> take advantage of short-circuit evaluation.
> 
> According to the profile report, I don't understand the logic of your
> patch.
> 
>>>> - org-footnote-in-valid-context-p 4106  44%
>>>> + org-inside-LaTeX-fragment-p 2380  25%
>>>> + org-in-block-p 1563  16%
>>>> + org-in-verbatim-emphasis 159   1%
> 
> ISTM that `org-in-block-p' is marginally slower (15%) than
> `org-inside-LaTeX-fragment-p' (9%).

I’m not sure where 15 and 9 come from.  The way I read the report,
org-footnote-in-valid-context-p takes 44% of the cumulative time, which
is composed of org-inside-LaTeX-fragment-p (25%) + org-in-block-p (16%)
+ other stuff (3%).  So org-inside-LaTeX-fragment-p accounts for >50% of
the time spent in org-footnote-in-valid-context-p.

> 
> Of course, in OP's report, `org-in-block-p' is the test returning early,
> so pushing it earlier is faster since you don't call
> `org-inside-LaTeX-fragment-p', but this is only a very specific
> optimization made at the expense of other cases (and contradicts your
> commit message). Am I missing something?

...no, you’re not missing anything.  I looked at my patch again, and it
seems completely dumb.  I should not write code before finishing my
morning cup of tea.  I reverted in a198d81.

> 
> I don't understand either the benefit of adding `not' calls all over the
> place. I generally use de Morgan's law the other way and save a few
> primcalls.
> 
>> Do [1]-type footnotes present other performance problems today?
> 
> The main problem of plain footnotes isn't really their performance, but
> false positives'. Anytime something looks like a footnote in a buffer,
> you get a performance hit. This happens much more often with plain
> footnotes than with other footnote types.
> 
> Moreover, false positives can introduce not-so-subtle problems during
> export (see for example 2c66e40c).
> 
> Note that suggesting to not use them (the default value, actually, per
> `org-footnote-auto-label') doesn't help, since false positives are the
> problem, not real footnotes.
> 
> Eventually, removing them doesn't remove any feature to Org. Of course,
> this is an incompatible change, and some users will need to update
> documents using plain footnotes. We can provide a function for that, and
> use `org-lint' to check for obsolete footnotes. The benefit is to avoid
> a whole class of problems.

I see.  Eventually it sounds like a good idea, indeed.  Maybe we should
use something a bit stronger than org-lint to warn of the deprecation.
What if opening a document with plain footnotes generated a warning?

Thanks,

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]