search envelope-o feed check
Home Unanswered Active Tags New Question
user comment-o

Change the height of the row without firing events for all rows

Asked by Atul Tatke
23 days ago.

I am trying to change the height of the a particular row. But after I change the height I need to call dp.Update() method. But that method fires all the events for all the rows. This is OK for small dataset but we have a big dataset (anywhere from 500 - 1000 rows) and multiple events per row ( so total events around 5000 to 10000) .
Due to a large number of events dp.Update() is taking quite a lot of time.
Is there a way to fire only certain rows level events without calling dp.Update() method?

Any help will be highly appreciated.

Answer posted by Dan Letecky [DayPilot]
18 days ago.

Unfortunately, it's not possible to update a single row at the moment. The full update ensures that the data and view are in sync and updating just a single row could have unwanted side effects and hard-to-find bugs.

I recommend switching to dynamic event loading ( so that the total number of events that need to be reloaded is reduced.

Comment posted by andy
9 days ago.

i agree that full update ensures that the data and view are in sync, but there are other ways to take care of that. however if we don't have single row update facility i don't find meaning in dealing with large data with this component.

Comment posted by Dan Letecky [DayPilot]
8 days ago.

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:

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.

New Reply
This reply is
Your name (optional):