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.