From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathaniel Flath Subject: Re: [PATH] Speedups to org-table-recalculate Date: Sat, 25 Oct 2014 17:27:25 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01538a127421f60506487a07 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiBg8-00023o-CJ for emacs-orgmode@gnu.org; Sat, 25 Oct 2014 20:27:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiBg7-0005L2-20 for emacs-orgmode@gnu.org; Sat, 25 Oct 2014 20:27:28 -0400 Received: from mail-oi0-x229.google.com ([2607:f8b0:4003:c06::229]:60344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiBg6-0005Ko-P3 for emacs-orgmode@gnu.org; Sat, 25 Oct 2014 20:27:26 -0400 Received: by mail-oi0-f41.google.com with SMTP id u20so1896619oif.28 for ; Sat, 25 Oct 2014 17:27:25 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Michael Brand Cc: org-mode List --089e01538a127421f60506487a07 Content-Type: text/plain; charset=UTF-8 Hi Michael On Mon, Oct 20, 2014 at 12:41 PM, Michael Brand wrote: > Hi Nathaniel > > On Mon, Oct 20, 2014 at 3:56 AM, Nathaniel Flath > wrote: > > Thanks for the review! Updated patches attached. I believe I've fixed > > everything you mentioned - > > Yes, thank you. I tried them out. > > > let me know if I missed something. > > > Subject: [PATCH 1/2] org-table.el: Add early return check to > > org-table-recalculate > > > Subject: [PATCH 2/2] org-table.el: Print far fewer messages when > recalculating > > tables. > > http://orgmode.org/worg/org-contribute.html > says: Line 2 is an empty line. > > I try to limit my commit subjects to 50 chars which is a rule for some > projects and helpful for e. g. git log with certain options. > OK, will fix these in next set of pathces. > > > + (and all (org-table-execute-once-per-second > > + log-last-time > > + (message > > + "Re-applying formulas to full table...(line %d)" > > + (setq cnt (1+ cnt))))) > > Before trying out I have overseen it, setq does not increment on each > line any more so it has to move before > org-table-execute-once-per-second. Now probably better wrapped in a > `when' instead of the original `and' with an added `progn'. > OK, good catch > > > + (org-table-execute-once-per-second > > + log-first-time > > + (message "Re-applying formulas...done" cnt)) > > cnt is superfluous. > OK. > > Only during trying out I noticed: This message could still be kept as > a feedback at least for single row updates, like e. g. Tab on a row > with "#" in the first column, by changing log-first-time to (when all > log-first-time). > > Or more conservative why not leave this message unconditional to avoid > that any user could complain for any use case that all feedback > messages disappeared like it would be the case for e. g. the typical > "C-c C-c" on TBLFM? I think that would be a simple, safe compromise. > I'm fine with adding the (when all log-first-time). I don't want to leave it unconditional because as we discussed before, one message in my case significantly slows down the table recalculation - and if there has been no feedback then we are dealing with a small case where it could be significant. > > Otherwise the right but not so simple thing to do would be to log this > message for a simple "C-c C-c" on TBLFM and to not log it for only > those cases that throw after other feedback messages like e. g. > sometimes "C-u C-u C-c C-c" on TBLFM ("Table was already stable"), M-x > org-table-iterate-buffer-tables and more. These repetition intensive > use cases are the only ones that can profit noticeable from the > conditional removal of this last message, aren't they? > I got tired of having to force tables to be reformated, so I advised org-cycle to always recalculate a table, so I notice whenever I'm in a table. > > Michael > --089e01538a127421f60506487a07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael

On Mon, Oct 20, 2014 at 12:41 PM, Michael Brand <michael.ch.brand@gmail.com> wrote:
Hi Nathaniel

On Mon, Oct 20, 2014 at 3:56 AM, Nathaniel Flath <flat0103@gmail.com> wrote:
> Thanks for the review! Updated patches attached.=C2=A0 I believe I'= ;ve fixed
> everything you mentioned -

Yes, thank you. I tried them out.

> let me know if I missed something.

> Subject: [PATCH 1/2] org-table.el: Add early return check to >=C2=A0 org-table-recalculate

> Subject: [PATCH 2/2] org-table.el: Print far fewer messages when recal= culating
>=C2=A0 tables.

h= ttp://orgmode.org/worg/org-contribute.html
says: Line 2 is an empty line.

I try to limit my commit subjects to 50 chars which is a rule for some
projects and helpful for e. g. git log with certain options.

OK, will fix these in next set of pathces.
=

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (and all (org-table-execute= -once-per-second
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 log-last-time
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 (message
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0"Re-applying formulas to full table...(line %d)" > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0(setq cnt (1+ cnt)))))

Before trying out I have overseen it, setq does not increment on each
line any more so it has to move before
org-table-execute-once-per-second. Now probably better wrapped in a
`when' instead of the original `and' with an added `progn'.
=

OK, good catch

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (org-table-execute-once-per-second
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0log-first-time
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(message "Re-applying formulas= ...done" cnt))

cnt is superfluous.

OK.
=C2=A0

Only during trying out I noticed: This message could still be kept as
a feedback at least for single row updates, like e. g. Tab on a row
with "#" in the first column, by changing log-first-time to (when= all
log-first-time).

Or more conservative why not leave this message unconditional to avoid
that any user could complain for any use case that all feedback
messages disappeared like it would be the case for e. g. the typical
"C-c C-c" on TBLFM? I think that would be a simple, safe compromi= se.

I'm fine with adding the (when = all log-first-time).=C2=A0 I don't want to leave it
unconditional b= ecause as we discussed before, one message in my case
=C2=A0significantl= y slows down the table recalculation - and if there has
=C2=A0been no fe= edback then we are dealing with a small case where it could be significant.=
=C2=A0

Otherwise the right but not so simple thing to do would be to log this
message for a simple "C-c C-c" on TBLFM and to not log it for onl= y
those cases that throw after other feedback messages like e. g.
sometimes "C-u C-u C-c C-c" on TBLFM ("Table was already sta= ble"), M-x
org-table-iterate-buffer-tables and more. These repetition intensive
use cases are the only ones that can profit noticeable from the
conditional removal of this last message, aren't they?
=

I got tired of having to force tables to be reformated,= so I advised
=C2=A0org-cycle to always recalculate a table, so I notice= whenever I'm in a table.

Michael

--089e01538a127421f60506487a07--