Re: [BUG] org-goto slows down org-set-property

[John Kitchin <jkitchin@andrew.cmu.edu>]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

This link (
https://stackoverflow.com/questions/36926513/are-there-elisp-functions-that-list-markers-in-a-given-buffer)
suggests there is not a good way to find all the markers associated with a
buffer.

John

-----------------------------------
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Mon, Jul 12, 2021 at 11:01 AM Maxim Nikulin <manikulin@gmail.com> wrote:

> On 11/07/2021 23:00, Ihor Radchenko wrote:
> > Maxim Nikulin writes:
> >
> >> Ihor, did you get that numbers using emacs -Q? If not, I suspect you may
> >> have twice more markers in the buffer than `org-refile-get-targets'
> >> usually generates. If my guess is correct it may be necessary to file a
> >> bug that org-ql or some other package abuses markers by generation to
> >> much of them.
> >
> > With emacs -Q things are twice better, though still not good enough:
> ...
> > org-ql might be one of the reasons of slowdown. Without it, the nm-tst
> > after clearing the cache is slightly faster (was 13 sec):
>
> 13.8 - 10.1 = 3.7 that is comparable with "emacs -Q" that is 5.3. So
> contribution of org-ql is not major one, but it is still significant.
>
> > However, markers are also created by agendas for example. The last
> > result is also on fresh Emacs. Fresh Emacs tends to be faster in general.
> >
> > Do you know a good way to find out all the markers associated with a
> buffer?
>
> I was going to ask you, but forgot to do it. Perhaps it is impossible by
> design.
>
> (length org-agenda-markers)
>
>
>

[-- Attachment #2: Type: text/html, Size: 2503 bytes --]