OK, let me explain in more detail:
1. If you have troubles with the update() duration it is an indication of possible performance issues which will affect the Scheduler performance in all areas. It might be a good idea to try to find them and optimize the code.
2. Using an update() call for all UI changes was a design decision which may not suit everyone but it allows to keep the API simple and understandable and to keep the Scheduler state consistent. It also shifts the focus to optimizations that improve the overall performance (and that includes internal Scheduler improvements and improvements of your application).
3. The possibility to refresh a single row might fix this particular issue but you'd soon hit another similar problem, requiring additional API call to micro-optimize it. This quickly turns the code into series of partial updates which you need to track. This introduces a good chance of getting the data and view out of sync. This results in random issues that are extremely hard to find. In that case, the Scheduler is the first target to blame but it's impossible to provide good support in such instances.
4. I performed a benchmark for a Scheduler view with 12,000 events displayed in 400 rows. Here are the reference update() call values:
(cpu):(duration)
i7-8700k: 340ms
i5-8250u: 750ms
Atom x5-z8300: 3000ms
On reasonably fast machines, the update takes less then 1s. If you are experiencing significantly loader update() time you may want to take a look at your onBeforeEventRender and other rendering event handlers.
5. Loading all events at once works well only up to a certain threshold. Although the raw benchmark from the previous paragraph might look acceptable, I would personally consider 10,000 too much and look for ways to reduce that (e.g. by switching to dynamic event loading). In the sample benchmark, those 12,000 events serialized to JSON resulted in 1,434,281 bytes which is a considerable load to transfer over the network.