Premium support for our pure JavaScript UI components


Post by Giovanni Pini »

Dear Bryntum team,

We noticed some performance degradation upgrading the Scheduler component from 3.0.4 to 4.0.7. We observed that with 150 events (10 resources, each with 15 events) the time required to render all the events on the UI is doubled (from 1 sec to 2 secs).

We've noticed there's a similar bug opened and solved on performances (viewtopic.php?f=51&t=16127). So we tried the latest nightly build (with the fix) but we still have the same bad performances.

Just to add some more info, we're using a custom "eventRenderer" and we're using the startBatch/endBatch. Even removing them as suggested in the thread mentioned above didn't change the things. Having a look the the Chrome Performance tool we also observed something weird that was not happening in Scheduler 3.x.x: "onElementResize" is triggered automatically and it's re-calculating all the HTML templates. This step alone is taking more or less 700ms and we don't have any clue about why and who is triggering it.

I'll attach some files like the performance data from Chrome Performance tool. All the measures have been taken on the same machine with Chrome 88.

Please let me know if you need any further info,
Giovanni

Attachments
bryntum-performances.zip
(923.26 KiB) Downloaded 89 times

Post by mats »

Can you please let us know how to reproduce what you are seeing in one of our basic examples? We need to see the pattern


Post by Giovanni Pini »

Actually there's a simple way to reproduce this exploiting the bigdataset example:

Let's consider a dataset of 5K events (200 resources * 25 events).

I obtain the following results:

Bryntum Scheduler 3.0.4
generate: 32.22 ms
data: 460.38 ms

Bryntum Scheduler 4.1.0-beta-1
generate: 123.47 ms
data: 838.54 ms


Post by pmiklashevich »

Hello,

It's expected that Scheduler 4.x is a bit slower than Scheduler 3.x. It happens due to the ported Scheduling Engine to Scheduler base classes. Though in simple Scheduler the Scheduling Engine shouldn't calculate anything. It should just create a project and prepare stores. We will try to optimize the code to make Scheduler 4.x work faster. Thank you for the feedback! https://github.com/bryntum/support/issues/2358

Best regards,
Pavel

Pavlo Miklashevych
Sr. Frontend Developer


Post by pmiklashevich »

Regarding the "onElementResize" function which takes about 700ms for you. I cannot reproduce it. You can see on the screenshot that it takes 0.17ms in Big dataset demo. Please submit a runnable testcase that we can inspect. Cheers!

Снимок экрана 2021-02-09 в 20.37.51.png
Снимок экрана 2021-02-09 в 20.37.51.png (243.1 KiB) Viewed 2183 times

Pavlo Miklashevych
Sr. Frontend Developer


Post by Giovanni Pini »

Thanks Pavel for taking care of this. Performances in our application are really important so we reverted to Scheduler 3.x. As soon as you have an ETA about the fix, can you please let us know?

About the "onElementResize", I'll have a deeper look and I'll see if I can reproduce it on a demo example.


Post by johan.isaksson »

Hi,

Regarding the data layer performance, it is expected to be slower in 4.x than in 3.x because it now always uses an AssignmentStore.

Old demo has 200 resources + 200 x 25 events = 5200 records.

New demo has 200 resource + 200 x 25 events + 200 x 25 assignments = 10200 records.

Supporting both having and not having an AssignmentStore was becoming unmaintainable. Also many features did not take multi assignment into account. Thus we traded some performance for maintainability and improved features in 4.0.

With that said, I think I can shave perhaps 15% of the data phase for new Scheduler. Still slower than the old, but because of the assignment records we wont be able to match the old version any time soon.

Best regards,
Johan Isaksson

Post by Giovanni Pini »

pmiklashevich wrote: Tue Feb 09, 2021 8:02 pm

Regarding the "onElementResize" function which takes about 700ms for you. I cannot reproduce it. You can see on the screenshot that it takes 0.17ms in Big dataset demo. Please submit a runnable testcase that we can inspect. Cheers!
Снимок экрана 2021-02-09 в 20.37.51.png

Regarding this one, we were able to identify what was causing "onElementResize" taking so long:

In our code we were doing something like:

schedulerEngine.resourceStore.beginBatch();
	
// Store modifications
	
schedulerEngine.eventStore.endBatch();

which was working fine in Bryntum 3.x.

Starting with Bryntum 4.x, "onElementResize" is taking really a long time since it's re-rendering everything if "refreshSuspended" is false (or zero). In our case what did the trick was having a look into the bigdataset demo code, we removed startBatch/endBatch and now our code looks like:

schedulerEngine.suspendRefresh();
	
// Store modifications
	
schedulerEngine.resumeRefresh(true);
await schedulerEngine.project.await('refresh');

Is that correct? We didn't find this documented in the changelog/upgrade section.

Anyway this is only solving the "onElementResize" part, we're still experiencing the performance issues described in the ticket.


Post by mats »

@Giovanni Pini: Please provide a clear test case so we can benchmark and see exactly what is going on.


Post by Giovanni Pini »

@mats: The test case for the "onElementResize" is visible on the bigdataset demo.
Bryntum Scheduler version: 4.1.0-beta-1 - 2021-01-15

Steps to reproduce:

  • Replace this line:

    scheduler.suspendRefresh();

    with:

    scheduler.eventStore.beginBatch();
    scheduler.resourceStore.beginBatch();
  • Replace these lines:

    scheduler.resumeRefresh(true);
    await scheduler.project.await('refresh');

    with:

    scheduler.eventStore.endBatch();
    scheduler.resourceStore.endBatch();
  • Set 5 resources x 25 events.

  • Start the performance profiler in Chrome Developer tool.

  • Change the resources to 20.

  • Stop the recording.

You can notice that the "onElementResize" is rendering all the rows. As soon as it finishes the async engine is rendering all the rows (again).

beginEndBatch-onElementResize.PNG
beginEndBatch-onElementResize.PNG (95.27 KiB) Viewed 2139 times

We've always used the beginBatch/endBatch in our code without any issue. With Bryntum 4.x we started seeing this heavy call to "onElementResize" and apparently only using suspendRefresh / resumeRefresh solves the problem.

I'll attach the json obtained from the profiler. Please let me know if we're missing something here.

Attachments
bigDataset-beginEndBatch-onElementResize.json
(6 MiB) Downloaded 100 times

Post Reply