Our pure JavaScript Scheduler component

Post by maxivalenzano »


I am working on a project in which we have the following number of entities:

  • 39 resources
  • 799 events
  • 1177 relations

The problem is that the model takes too long when I apply certain custom logics after loading the data.
These logics try to avoid overlaps and minimize gaps between events.

One of the logics, for example, goes through each event in each resource, detects if there is an overlap with the previous event, and if so, adjusts its start date, like this:

event.setStartDate(refDate, true);
event.startDateConstraintIntervals = [];
await event.project.commitAsync();

For each event it modifies, it calls commitAsync because as the logic moves forward with the next event, it requires to have the updated endDate considering resource calendar and dependencies.

I was applying

event.startDateConstraintIntervals = [];

because at some point (maybe a previous bryntum version), it locked tasks if that wasn't applied.

I tried changing the previous code with:

await event.setStartDate(refDate, true);

but it is still slow.

Do you have suggestions for improvements? Maybe similar code examples?


Post by mats »

Can you please share your full code so we can see? Sounds like it could be optimized.

Post by maxivalenzano »

this is one of the functions.

    async removeOverlap(fixedTasks, tasks) {
        fixedTasks.sort((a, b) => (a.startDate > b.startDate ? 1 : 
            a.startDate < b.startDate ? -1 : 
            a.endDate > b.endDate ? 1 : -1));
        tasks.sort((a, b) => (a.startDate > b.startDate ? 1 : -1));

    let index = 0;
    for (const event of tasks) {
        const previousEvent = tasks[index - 1];
        if (previousEvent) {
            const setupTime = event.preamble ? event.preamble.magnitude : 0;
            const setupUnit = event.preamble ? event.preamble.unit : 'minute';
            const potentialStartDate = DateHelper.add(previousEvent.endDate, setupTime, setupUnit);

            if (potentialStartDate > event.startDate) {
                await event.setStartDate(potentialStartDate, true);


Post by mats »

It's the looping that's the cause of the bad performance.

Do you need to await after each? If not, just await project.commitAsync() after you have modified all events. Also you should call suspendRefresh before making batch commits, then resumeRefresh() after. This should speed it up a lot.

Post by maxivalenzano »

Thanks for the reply. By the way, I'm using scheduler pro.
I am applying await for each because, as it is looping, it requires the updated endDate of the previous event to determine the startDate.
Is there another way to achieve this?

The suspend and resume already improved performance a lot.

Post by Animal »

Isn 't this code doing what dependencies do automatically in ShedulerPro?


Screenshot 2024-06-07 at 07.51.09.png
Screenshot 2024-06-07 at 07.51.09.png (80.48 KiB) Viewed 140 times

Post by maxivalenzano »

No, with the dependencies the sequence remains fixed.
The code seeks to remove overlaps when the user starts changing the sequence.

Post by mats »

Right, then that's probably the best option. Is performance acceptable now, or still too slow?

Post by maxivalenzano »

performance is acceptable for now, but we will have confirmation with real workload in the upcoming weeks.
I'll write in any case, thanks for checking.

Post Reply