From: Max Nikulin <email@example.com>
Subject: Re: profiling latency in large org-mode buffers (under both main & org-fold feature)
Date: Thu, 3 Mar 2022 21:56:33 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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.
next prev parent reply other threads:[~2022-03-03 14:57 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 21:06 profiling latency in large org-mode buffers (under both main & org-fold feature) Matt Price
2022-02-21 22:22 ` Samuel Wales
2022-02-22 5:33 ` Ihor Radchenko
2022-02-22 5:44 ` Kaushal Modi
[not found] ` <CAN_Dec8kW5hQoa0xr7sszafYJJNmGipX0DA94DKNh11DWjce8g@mail.gmail.com>
2022-02-23 2:41 ` Matt Price
2022-02-23 5:22 ` Ihor Radchenko
2022-02-23 14:47 ` Matt Price
2022-02-23 15:10 ` Ihor Radchenko
2022-02-22 21:11 ` Rudolf Adamkovič
2022-02-23 12:37 ` Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature)) Ihor Radchenko
2022-02-23 16:43 ` Kaushal Modi
2022-02-25 14:30 ` Ihor Radchenko
2022-02-26 12:04 ` Ihor Radchenko
2022-02-26 12:51 ` Ihor Radchenko
2022-02-26 15:51 ` Quiliro Ordóñez
2022-03-23 10:57 ` #2 Org mode profiling meetup on Sat, Mar 26 (was: Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature))) Ihor Radchenko
2022-03-24 11:17 ` Ihor Radchenko
2022-03-24 11:27 ` Bruce D'Arcus
2022-03-24 13:43 ` Matt Price
2022-03-24 13:49 ` Ihor Radchenko
2022-03-26 11:59 ` Ihor Radchenko
2022-03-27 8:14 ` Ihor Radchenko
2022-04-21 8:05 ` #3 Org mode profiling meetup on Sat, Apr 23 (was: #2 Org mode profiling meetup on Sat, Mar 26) Ihor Radchenko
2022-04-23 12:08 ` Ihor Radchenko
2022-04-24 4:27 ` Ihor Radchenko
2022-02-27 7:41 ` Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature)) Ihor Radchenko
2022-02-23 16:03 ` profiling latency in large org-mode buffers (under both main & org-fold feature) Max Nikulin
2022-02-23 16:35 ` Ihor Radchenko
2022-02-25 12:38 ` Max Nikulin
2022-02-26 7:45 ` Ihor Radchenko
2022-02-26 12:45 ` Max Nikulin
2022-02-27 6:43 ` Ihor Radchenko
2022-03-02 12:23 ` Max Nikulin
2022-03-02 15:12 ` Ihor Radchenko
2022-03-03 14:56 ` Max Nikulin [this message]
2022-03-19 8:49 ` Ihor Radchenko
2022-02-26 15:07 ` Jean Louis
2022-02-23 2:39 ` Matt Price
2022-02-23 5:25 ` Ihor Radchenko
2022-02-22 5:30 ` Ihor Radchenko
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).