emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: Asynchronous org-agenda-redo
Date: Mon, 16 Dec 2019 04:32:25 -0600	[thread overview]
Message-ID: <87v9qgr26e.fsf@alphapapa.net> (raw)
In-Reply-To: 878sncohs9.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me

Ihor Radchenko <yantar92@gmail.com> writes:

>> So, of course, you can call custom functions in queries, even your
>> own skip functions (with `not', of course), but in most cases, they
>> can be covered with built-in predicates.
>
> Unfortunately, it does not seem to be the case for me.  My main agenda
> view needs to take into account multiple properties, which cannot be
> handled within framework of built-in org-ql predicates (AFAIK):
>
> - =:SHOWFROMTIME:= (always inheriting) :: The purpose of this is to be
>      able to assign specific projects for different days of week or,
>      say, show the home items only in the evening of weekdays and not
>      annoy me at work when I cannot do it any way. Hence, I can focus on
>      the items I really need to do now in this agenda. Additionally, the
>      time of the day after midnight is treated specially here. If
>      =org-extend-today-until= is not 0 and the current time is before
>      its value, the current time is still considered to be yesterday.
> - =:SHOWFROMDATE:= :: The purpose of this is to be able to postpone the
>      scheduled tasks for future if I cannot do it. The property is
>      formatted as an org date. This property is especially useful if
>      there is something more pressing, so that there is a temptation to
>      reschedule less pressing event to another day. If the more pressing
>      task is done earlier than expected, the postponed tasks can be
>      still find in normal agenda view (not in the
>      [[id:ff70b03f-3876-4b2b-9aab-c3209bd31cb8][focused]] one).
> - =:SHOWDATES:= (always inheriting) :: It contains dairy =sexps= to set
>      when the project should be shown. For example, I may want to work on
>      Saturday once or twice, but the working items should not be shown on
>      weekend normally. Hence, I can define it. Or some things can only be
>      done on specific dates (say, going to some shop, which is open few
>      days a week only)

There may still be some performance improvement available for these kind
of queries.  For example, assuming that a function `yantar/showfromdate'
is a predicate which accepts the value of property SHOWFROMDATE as its
argument and returns non-nil when an entry matches a query, an org-ql
query like this could work:

    (and (property "SHOWFROMDATE")
         (yantar/showfromdate (property "SHOWFROMDATE")))

The first (property "SHOWFROMDATE") clause allows org-ql to optimize the
query using a regexp preamble that jumps directly to entries having that
property, while the second clause passes the value of the property to
the custom predicate using the built-in predicate (property
"SHOWFROMDATE") to retrieve the property from the org-ql node-value
cache, which reduces the number of calls to org-entry-get.  (That the
`property' predicate returns the value of the property when called with
only a property argument is a helpful feature that I should document...)

> Thanks for the info! I did not know about this optimisation in org-ql.
> org-entry-get consumes most of cpu time while building my agenda views.
> Though I don't think that there will be much difference for me since
> most of my property conditions in agenda involve inherited properties.

For properties using inheritance, the preamble regexp can't be used to
optimize the query across the buffer (I have some ideas about how to do
that, maybe someday...), but the node-value cache can improve
performance of retrieving the values of inherited properties within a
buffer, because it avoids repeated calls to org-entry-get going up an
outline tree.

For example, see the benchmark here:

https://github.com/alphapapa/org-ql/blob/master/notes.org#caching-of-inherited-tags

The node-value cache, which is used for properties, uses essentially the
same code as the tag cache benchmarked here (I haven't yet converted the
tag cache to use the generic node-value cache), and it provides about a
6x speedup, so property-inheritance-based queries should benefit
similarly.

So it sounds like your custom agendas would benefit from being written
as org-ql queries.  Please let me know if you try it, as your examples
would give the code a good workout and might reveal some improvements to
be made.

  reply	other threads:[~2019-12-16 10:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12  8:18 Asynchronous org-agenda-redo Ihor Radchenko
2019-12-12 12:17 ` Adam Porter
2019-12-12 15:46   ` Ihor Radchenko
2019-12-13  6:49     ` Adam Porter
2019-12-13  8:35       ` Ihor Radchenko
2019-12-13  9:39         ` Ihor Radchenko
2019-12-14  4:59           ` Adam Porter
2019-12-22  6:54             ` Ihor Radchenko
2019-12-24  0:36               ` Adam Porter
2019-12-14  4:50         ` Adam Porter
2019-12-16  7:23           ` Ihor Radchenko
2019-12-16 10:32             ` Adam Porter [this message]
2019-12-12 12:51 ` Diego Zamboni
2019-12-12 14:58   ` Ihor Radchenko
2019-12-15 11:56     ` Asynchronous org-babel-tangle (was Re: Asynchronous org-agenda-redo) Diego Zamboni
2019-12-15 13:40       ` Ihor Radchenko
2019-12-15 13:41       ` Ihor Radchenko

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9qgr26e.fsf@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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).