From mboxrd@z Thu Jan  1 00:00:00 1970
From: Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: [PATCH] Optimize org-habit-parse-todo
Date: Tue, 25 Jan 2011 22:59:23 +0100
Message-ID: <6A096802-E737-45F7-A18B-7FD6B0389151@gmail.com>
References: <87mxmxys27.fsf@fastmail.fm>
	<AC5827C8-A200-4F6D-94D5-0673212CC781@gmail.com>
	<3410A977-FA48-4EF3-9868-13A932FFD1DB@gmail.com>
	<87sjwgn42k.fsf@fastmail.fm>
Mime-Version: 1.0 (Apple Message framework v936)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from [140.186.70.92] (port=52062 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PhqvA-0003Iu-Uj
	for emacs-orgmode@gnu.org; Tue, 25 Jan 2011 16:59:31 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <carsten.dominik@gmail.com>) id 1Phqv9-0004Ik-4F
	for emacs-orgmode@gnu.org; Tue, 25 Jan 2011 16:59:28 -0500
Received: from mail-ey0-f169.google.com ([209.85.215.169]:33537)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <carsten.dominik@gmail.com>) id 1Phqv8-0004Ia-W9
	for emacs-orgmode@gnu.org; Tue, 25 Jan 2011 16:59:27 -0500
Received: by eyh6 with SMTP id 6so220936eyh.0
	for <emacs-orgmode@gnu.org>; Tue, 25 Jan 2011 13:59:26 -0800 (PST)
In-Reply-To: <87sjwgn42k.fsf@fastmail.fm>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: Matt Lundin <mdl@imapmail.org>
Cc: Org Mode <emacs-orgmode@gnu.org>

Applied, thanks.

- Carsten

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
>  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 <carsten.dominik@gmail.com> 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
>