Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Bastien]

Ihor Radchenko  writes:

> Apparently 'org-marker property must always point to the beginning of
> timestamp. Fixed in latest main.

Confirmed, thanks a lot!

-- 
 Bastien

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Bastien  writes:

> with latest main, I cannot use S- (org-agenda-do-date-later) to
> update the entry at point.
>
> Here is the backtrace I get:
>
> Debugger entered--Lisp error: (error "Cannot find time stamp")
>   error("Cannot find time stamp")

Apparently 'org-marker property must always point to the beginning of
timestamp. Fixed in latest main.

Best,
Ihor

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Bastien  writes:
>
>> If you feel confident the change is mature enough for being merged
>> into the main branch, please go ahead, this will boost the feedback.
>
> Merged to main just now.

with latest main, I cannot use S- (org-agenda-do-date-later) to
update the entry at point.

Here is the backtrace I get:

Debugger entered--Lisp error: (error "Cannot find time stamp")
  error("Cannot find time stamp")
  (if (org-at-timestamp-p 'lax) nil (error "Cannot find time stamp"))
  (save-current-buffer (set-buffer buffer) (widen) (goto-char pos) (if
  (org-at-timestamp-p 'lax) nil (error "Cannot find time stamp")) (if
  (and org-agenda-move-date-from-past-immediately-to-today (equal arg
  1) (or (not what) (eq what 'day)) (not (let
  ((save-match-data-internal (match-data))) (unwind-protect (progn
  (org-at-date-range-p)) (set-match-data save-match-data-internal
  'evaporate) (progn (setq cdate (org-parse-time-string
  (match-string 0) 'nodefault) cdate (calendar-absolute-from-gregorian
  (list (nth 4 cdate) (nth 3 cdate) (nth 5 cdate))) today (org-today))
  (if (> today cdate) (progn (setq arg (- today cdate))
  (org-timestamp-change arg (or what 'day)) (if (and
  (org-at-date-range-p) (re-search-backward org-tr-regexp-both
  (point-at-bol))) (progn (let ((end org-last-changed-timestamp))
  (org-timestamp-change arg (or what 'day)) (setq
  org-last-changed-timestamp (concat org-last-changed-timestamp "--"
  end))

Let me know if I need to investigate more.

Thanks!

-- 
 Bastien

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Bastien]

Ihor Radchenko  writes:

> Bastien  writes:
>
>> If you feel confident the change is mature enough for being merged
>> into the main branch, please go ahead, this will boost the feedback.
>
> Merged to main just now.

Thanks!

-- 
 Bastien

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Bastien  writes:

> If you feel confident the change is mature enough for being merged
> into the main branch, please go ahead, this will boost the feedback.

Merged to main just now.

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Bastien  writes:

> If you feel confident the change is mature enough for being merged
> into the main branch, please go ahead, this will boost the feedback.

Merged to main just now.

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Timothy  writes:
>> Ah, I’ve already got a few patches on Org that I’m preparing for sharing on 
>> the
>> ML, so this may make it a bit harder for me. I’ll let you know how I find it 
>> if
>> I do give it a go though.
>
> My repo is up-to-date with latest master. 

If you feel confident the change is mature enough for being merged
into the main branch, please go ahead, this will boost the feedback.

Thanks!

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Timothy  writes:
> Ah, I’ve already got a few patches on Org that I’m preparing for sharing on 
> the
> ML, so this may make it a bit harder for me. I’ll let you know how I find it 
> if
> I do give it a go though.

My repo is up-to-date with latest master. You should be able to merge
without too much trouble. I think you can even add my repo to git
remotes, fetch feature/org-fold-universal-core branch, and merge it with
your local testing branch.

Best,
Ihor

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Timothy]

Hi  Ihor,

Thanks for clearing up the nature of your patch-y feature request.

>> p.s. I’m marking this as a patch on the tracker, since it is one :P
>
> This is not a real patch. I just separated changes I made in
> org-element.el. Other changes include cache support across Org code and
> tests. In total it looks roughly like:
>
> 12 files changed, 2584 insertions(+), 1140 deletions(-)
>
> However, I did not directly base the patch on master, but rather on
> (hopefully-to-be-merged-at-some-point org-fold branch :’/). I am not too
> interested in porting the patch onto master. At least not until I get
> feedback on parser and API changes.

Righteo, I’ll un-mark this as a patch then 🙂.

>> As someone who tangles massive literate config this sounds like it could make
>> quite a noticeable improvement. To test this, do I need to do anything more 
>> than
>> just apply your patch?
>
> Applying the patch will not work. As I said, it is mostly for reference
> to show the changes to parser and API. If you want to test it, you can
> use . That repo includes the org-fold
> branch and the new cache implementation.

Ah, I’ve already got a few patches on Org that I’m preparing for sharing on the
ML, so this may make it a bit harder for me. I’ll let you know how I find it if
I do give it a go though.

All the best,
Timothy

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Timothy  writes:

> p.s. I’m marking this as a patch on the tracker, since it is one :P

This is not a real patch. I just separated changes I made in
org-element.el. Other changes include cache support across Org code and
tests. In total it looks roughly like:

12 files changed, 2584 insertions(+), 1140 deletions(-)

However, I did not directly base the patch on master, but rather on
(hopefully-to-be-merged-at-some-point org-fold branch :'/). I am not too
interested in porting the patch onto master. At least not until I get
feedback on parser and API changes.

> As someone who tangles massive literate config this sounds like it could make
> quite a noticeable improvement. To test this, do I need to do anything more 
> than
> just apply your patch?

Applying the patch will not work. As I said, it is mostly for reference
to show the changes to parser and API. If you want to test it, you can
use https://github.com/yantar92/org. That repo includes the org-fold
branch and the new cache implementation.

Best,
Ihor

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Timothy]

Hi  Ihor,

I’ve just read through your description, and this sounds very promising! Many
thanks for going to the effort of tracking down this performance issue and
/actually making a patch to address it/.

As someone who tangles massive literate config this sounds like it could make
quite a noticeable improvement. To test this, do I need to do anything more than
just apply your patch?

> I would like to propose adding support of storing headlines in
> org-element-cache.
>
> Currently, org-element-cache only stores elements within individual
> sections. Storing headlines in cache would open various possibilities to
> improve Org performance: tag inheritance, property inheritance, category
> queries, id lookup, refile targets, agenda views, etc could all make use
> of cache.
>
> I am not proposing a mere idea, but have an actual working (WIP) code
> in: . Also, I am attaching a reference
> patch for org-element.el (the actual branch contains more changes).

All the best,
Timothy

p.s. I’m marking this as a patch on the tracker, since it is one :P