From: Carsten Dominik <email@example.com>
To: Matt Lundin <firstname.lastname@example.org>
Cc: Org Mode <email@example.com>
Subject: Re: [PATCH] Optimize org-habit-parse-todo
Date: Tue, 25 Jan 2011 22:59:23 +0100 [thread overview]
Message-ID: <6A096802-E737-45F7-A18B-7FD6B0389151@gmail.com> (raw)
On Jan 25, 2011, at 9:03 PM, Matt Lundin wrote:
> * lisp/org-habit.el: (org-habit-parse-todo) Don't parse more days than
> When constructing a consistency graph, org-habit now stops searching
> for timestamps when the number of matches exceeds the span of time
> displayed in the graph. This can lead to a significant speedup in
> agenda construction, especially for entries with many logbook entries.
> Previously, org-habit would parse all logbook timestamps, even if they
> numbered in the hundreds.
> lisp/org-habit.el | 16 ++++++++++++----
> 1 files changed, 12 insertions(+), 4 deletions(-)
> diff --git a/lisp/org-habit.el b/lisp/org-habit.el
> index b174a1f..5d2514a 100644
> --- a/lisp/org-habit.el
> +++ b/lisp/org-habit.el
> @@ -170,10 +170,18 @@ This list represents a \"habit\" for the rest
> of this module."
> habit-entry scheduled-repeat))
> (setq deadline (+ scheduled (- dr-days sr-days))))
> (org-back-to-heading t)
> - (while (re-search-forward "- State \"DONE\".*\\[\\([^]]+\\)\
> \]" end t)
> - (push (time-to-days
> - (org-time-string-to-time (match-string-no-properties 1)))
> - closed-dates))
> + (let* ((maxdays (+ org-habit-preceding-days org-habit-
> + (reversed org-log-states-order-reversed)
> + (search (if reversed 're-search-forward 're-search-backward))
> + (limit (if reversed end (point)))
> + (count 0))
> + (unless reversed (goto-char end))
> + (while (and (< count maxdays)
> + (funcall search "- State \"DONE\".*\\[\\([^]]+\\)\\]" limit t))
> + (push (time-to-days
> + (org-time-string-to-time (match-string-no-properties 1)))
> + closed-dates)
> + (setq count (1+ count))))
> (list scheduled sr-days deadline dr-days closed-dates))))
> (defsubst org-habit-scheduled (habit)
> Carsten Dominik <firstname.lastname@example.org> writes:
>> On Jan 25, 2011, at 7:01 AM, Carsten Dominik wrote:
>>> Hi Matt
>>> this looks like a very important optimisation indeed.
>>> I am just wondering if it is always safe to do it like
>>> this. Have you checked if this is influenced by
>>> org-reverse-notes-order or similar things?
>> I am sorry, I see now that this is done correctly.
>> One request, can you resubmit and test for the count
>> first, before doing the search? Just another very
>> minor optimization.
> Thanks Carsten!
> See the updated patch above. The next step is to make the keyword
prev parent reply other threads:[~2011-01-25 21:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 12:39 [PATCH] Optimize org-habit-parse-todo Matt Lundin
2011-01-25 6:01 ` Carsten Dominik
2011-01-25 6:21 ` Carsten Dominik
2011-01-25 20:03 ` Matt Lundin
2011-01-25 21:59 ` [Accepted] " Carsten Dominik
2011-01-25 21:59 ` Carsten Dominik [this message]
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).