emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATH] Speedups to org-table-recalculate


From: Nathaniel Flath
Subject: Re: [O] [PATH] Speedups to org-table-recalculate
Date: Fri, 10 Oct 2014 12:43:29 -0700

Mine is a pretty simple table (takes less than a second even in the original case):

| Category | Budget | Spent | Remaining |
|----------+--------+-------+-----------|
| A        |    100 |     0 |       100 |
| B        |    100 |     0 |       100 |
| C        |    100 |     0 |       100 |
| D        |    100 |     0 |       100 |
| E        |    100 |     0 |       100 |
| F        |    100 |     0 |       100 |
| G        |    100 |     0 |       100 |
| H        |    100 |     0 |       100 |
| I        |    100 |     0 |       100 |
| J        |    100 |     0 |       100 |
| K        |    100 |     0 |       100 |
| L        |    100 |     0 |       100 |
| M        |    100 |     0 |       100 |
| N        |    100 |     0 |       100 |
| O        |    100 |     0 |       100 |
| K        |    100 |     0 |       100 |
|----------+--------+-------+-----------|
| Total    |   1600 |     0 |      1600 |

#+TBLFM: $4=$2-$3::@18$2=vsum(@address@hidden)::@18$3=vsum(@address@hidden)

With the macro:
(defmacro time (block)
  `(let (start end)
    (setq start (current-time))
    ,block
    (setq end (current-time))
    (print (time-subtract end start))))
and running (time (org-table-recalculate t))

Original recalculation:  (0 0 396224 0)
Version w/ time checks for per-field messages (still always printing at beginning/end of processing):(0 0 56929 0)
Version w/ time checks and removing all beginning/end of processing messages: (0 0 22077 0)
My patch:  (0 0 17405 0)

So, it's still a  26% performance degradation to going with the patch and removing the 'global' messaging, but I could probably live with that - qualitatively, there doesn't seem to be too much difference between my patch and doing that, but the original version is obviously slow and with the on-begin/end calculation messages the delay is much more noticable.

On Fri, Oct 10, 2014 at 3:35 AM, Michael Brand <address@hidden> wrote:
Hi Nathaniel

On Fri, Oct 10, 2014 at 7:56 AM, Nathaniel Flath <address@hidden> wrote:
> That's still much more slow than not doing it - slightly modifying your
> example,:
>
> (progn
>   (setq start (current-time))
>   (let ((row 0) (log (time-add (current-time) '(0 1 0 0))))
>     (while (< row 6543210)
>       (setq row (1+ row))
>       (when (time-less-p log (current-time))
>         (setq log (time-add (current-time) '(0 1 0 0)))
>         (message "row %d" row))))
>   (setq end (current-time))
>   (print (time-subtract end start)))
>
> prints (0 43 386499 0) on my computer.
>
> Removing the when clause:
>
> (progn
>   (setq start (current-time))
>   (let ((row 0) (log (time-add (current-time) '(0 1 0 0))))
>     (while (< row 6543210)
>       (setq row (1+ row))))
>   (setq end (current-time))
>   (print (time-subtract end start)))
>
> Results in:
> (0 1 277641 0)
>
> So adding the logging here slows it down by about 43x - It doesn't seem
> worth it.

Your measurement shows that "(when (time-less-p log (current-time))
[...]" takes 6.4 microseconds or can run 150'000 times per second. I
would expect it to be negligible compared to what Org has to do for
each row or field like parse, calculate, format etc. Otherwise it
would mean that Org can perform more or not significantly less than
150'000 rows or fields per second on an appropriate example table.

Tersely formulated I expect this performance comparison: nothing or
empty loop << a conditional message with time check << Org performs a
simple formula on one row or field << an unconditional message

Can you make a performance comparison on your table between (a) your
patch and (b) without your patch but with "(when (time-less-p log
(current-time)) [...]" plus describe or share this table?

Michael


reply via email to

[Prev in Thread] Current Thread [Next in Thread]