Re: profiling latency in large org-mode buffers (under both main & org-fold feature)

[Max Nikulin <manikulin@gmail.com>]

On 02/03/2022 22:12, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> I tend to agree after reading the code again.
> I tried to play around with that marker loop. It seems that the loop
> should not be mindlessly disabled, but it can be sufficient to check
> only a small number of markers in front of the marker list. The cached
> temporary markers are always added in front of the list.

I did not try to say that the loop over markers may be just thrown away. 
By the way, for sequential scan (with no backward searches) single 
marker might work reasonably well.

Some kind of index for fast mapping between bytes and positions should 
be maintained at the buffer level. I hope, when properly designed, such 
structure may minimize amount of recalculations on each edit. I mean 
some hierarchical structure of buffer fragments and markers keeps 
relative offsets from beginning of the fragment they belong to. 
Hierarchy of fragments is enough to provide initial estimation of 
position for byte index. Only markers within the fragment that is 
changed need immediate update.

> I am currently using a custom version of org-ql utilising the new
> element cache. It is substantially faster compared to current
> org-refile-get-targets. The org-ql version runs in <2 seconds at worst
> when calculating all refile targets from scratch, while
> org-refile-get-targets is over 10sec. org-ql version gives 0 noticeable
> latency when there is an extra text query to narrow down the refile
> targets. So, is it certainly possible to improve the performance just
> using high-level org-element cache API + regexp search without markers.

It is up to you to choose at which level your prefer to optimize the 
code. And it is only my opinion (I do not insist) that benefits from 
changes in low level code might be much more significant. I like the 
idea of markers, but their current implementation is a source of pain.

> (note that Nicolas did not use
> markers to store boundaries of org elements).

E.g. export-related code certainly does need markers. You experienced 
enough problems with attempts to properly invalidate cache when lower 
level is not supposed to provide appropriate facilities.