[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] [PATCH] Optimize org-habit-parse-todo
From: |
Matt Lundin |
Subject: |
Re: [Orgmode] [PATCH] Optimize org-habit-parse-todo |
Date: |
Tue, 25 Jan 2011 15:03:47 -0500 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) |
* lisp/org-habit.el: (org-habit-parse-todo) Don't parse more days than
needed.
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-following-days))
+ (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)
--
1.7.3.5
Carsten Dominik <address@hidden> writes:
> On Jan 25, 2011, at 7:01 AM, Carsten Dominik wrote:
>
>> Hi Matt
>>
>> Hmmm,
>>
>> 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 search
configurable....
Best,
Matt