emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
	Derek Feichtinger <derek.feichtinger@psi.ch>
Cc: emacs-orgmode@gnu.org
Subject: Re: footnote fontify causing massive slowdown
Date: Sat, 05 Dec 2015 15:55:48 +0000	[thread overview]
Message-ID: <87bna43n5n.fsf@gmail.com> (raw)
In-Reply-To: <87610crjr7.fsf@nicolasgoaziou.fr>

Hi Nicolas,

2015ko abenudak 5an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <aaronecay@gmail.com> 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	other threads:[~2015-12-05 15:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04  7:15 footnote fontify causing massive slowdown Derek Feichtinger
2015-12-05 12:58 ` Nicolas Goaziou
2015-12-05 13:47   ` Aaron Ecay
2015-12-05 15:35     ` Nicolas Goaziou
2015-12-05 15:55       ` Aaron Ecay [this message]
2015-12-06  9:41         ` Nicolas Goaziou
2015-12-05 21:40   ` Alan L Tyree
2015-12-05 21:45     ` Matt Lundin
2015-12-05 23:42   ` Rasmus
2015-12-06  0:16   ` Samuel Wales
2015-12-06  0:58   ` William Denton
2015-12-06  1:18     ` Thomas S. Dye
2015-12-06  9:42       ` Nicolas Goaziou
  -- strict thread matches above, loose matches on Subject: below --
2015-12-03  7:17 Derek Feichtinger

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=87bna43n5n.fsf@gmail.com \
    --to=aaronecay@gmail.com \
    --cc=derek.feichtinger@psi.ch \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /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).