Michael Brand <michael.ch.br...@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>
