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(@2$2..@-1)::@18$3=vsum(@2$3..@-1)

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 <michael.ch.brand@gmail.com>
wrote:

> Hi Nathaniel
>
> On Fri, Oct 10, 2014 at 7:56 AM, Nathaniel Flath <flat0103@gmail.com>
> 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
>