emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Michael Brand <michael.ch.brand@gmail.com>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Performance of property drawers in Org cache
Date: Sun, 22 Dec 2024 14:37:02 +0000	[thread overview]
Message-ID: <87zfkn7pip.fsf@localhost> (raw)
In-Reply-To: <CALn3zogxNzhZso2z33CYoNsH0UtjKU=6i--09gNUReWj-pWt6Q@mail.gmail.com>

Michael Brand <michael.ch.brand@gmail.com> writes:

> Now I would like to report issues with the performance of property
> drawers in Org cache. The time it takes to open an Org file with a
> useful amount of property drawers like in test_1.org has increased too
> much for me to update from Org mode 9.5, see the table below.

This is because of new `org-cycle-hide-drawer-startup' that is set to t
by default. Previously, drawers were not folded on startup. Instead, they
were folded every time you unfold a heading, via `org-cycle-hook' (it no
longer contains `org-cycle-hide-drawers' entry by default).

This change was a tradeoff. Folding many drawers can be expensive, and we
increased the time for opening an Org buffer in exchange for faster
folding later.

> Org loading performance has also degraded a bit but I assume and hope
> that the amount is not more than necessary for the convenience of
> having more Org features preloaded.

This is hard to control, unfortunately. Org libraries are so much
entangled together that almost everything has to be loaded every time
you load Org. I hope to address this, but it is not a trivial task.

> To do some homework I looked in Org news, the mailing list, the
> Commentary of org-element-ast.el and an overview of
> org-element-ast.el. The beginning of the result of
> ~(org-element-cache-map #'car :granularity 'element)~ (as found in
> test-org-element.el) and its length of 3003 for test_1.org look
> completely reasonable to me. ~org-element--cache-map-statistic t~ does
> not reveal where the by far large rest of the total time goes: "Total
> time: 10.668449 sec. Pre-process time: 0.000000 sec. Predicate time:
> 0.014772 sec. Re-search time: 0.000000 sec.". I am surprised that a
> repeated use of ~org-element-cache-map~ is still quite slow: 2.0 s
> without statistic for iterating over 3003 cached AST nodes to collect
> their ~car~?. Obviously I am a bit overchallenged with the Org cache
> and hope that someone can look into this.

This is what I am getting on your test_1.org:

Mapped over elements in #<buffer test_1.org>. 3006/3006 predicate matches. Total time: 0.275971 sec. Pre-process time: 0.000000 sec. Predicate time: 0.002361 sec. Re-search time: 0.000000 sec.

In this case, it is very important that Org mode should be compiled.

> Out of curiosity: What consumes time during killing an Org buffer that
> seems to scale with the buffer/cache size? What has to be done more
> than just garbage collection that can be deferred to after killing has
> finished?

org-element-cache-persistent: writing parser cache to disk.
May it be deferred? It might, I think. But Emacs will be blocked at some
point anyway while doing so.

You can disable writing cache, if it is what you prefer.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


      reply	other threads:[~2024-12-22 14:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 15:41 Performance of property drawers in Org cache Michael Brand
2024-12-22 14:37 ` Ihor Radchenko [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=87zfkn7pip.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=michael.ch.brand@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).