Re: Performance of property drawers in Org cache

[Ihor Radchenko]

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>