Why ssuch a low tmer limit?

[ESPNSTI]

Given the way microprocessors are continuously improved, it may be the limit of the 622, but the 722 may have more power. The 922 would still have more processing power. I can see them keeping the limit on the 622, but the 722 and 922 should have the limit adjusted to better reflect their processing power.

I would agree with that if I thought that the slowdown was linear, however from what I can tell the performance degradation is non-linear.
For example if you only have 1 timer and you add 1, you experience some performance loss.
However if you have 95 timers and you add 1, you experience many, many times more performance loss than when you went from 1 to 2 timers.

If that is indeed the case, then you can maybe push the limit somewhat on the 722 and 922, but you probably can't take it too far since the non-linear increase of performance loss on the timers beyond the 96 mark will rapidly make up for any hardware difference.

What would probably be needed to be able to really push the limits is to either rewrite the scheduling portion of the software so that it can handle additional timers / events with near linear effect on performance.
Or rewrite the timer / event management portion of the software so that it behaves asynchronously. What this would mean is that if you press skip on an event, it would still take just as long as it does now, however it would let you do other things while it's in the process of skipping the event.
Both of these things would take a lot of effort to implement I suspect, so I doubt that would happen anytime soon.

 

[KKlare]

When you add the first timer there are no conflict checks but for n timers there will be n*n/2 or so checks, where n is the number of events or events + timers. This means as you get to 96 timers or 500+ events, each addition gets more "expensive" of time.
-Ken