gantt chart parse call taking > 20 seconds

I’ve done some profiling and narrowed the bottle neck down to the gantt.parse() line in my code. It takes over 20 seconds to return.

Once the data is rendered it works great. There are no performance issues at all.

I have a moderately complex data set, almost 1400 records long.

I’ve gone through all the optimizing tips I can’t find in the documentation, even though they only seem to be around performance tweaking not data loading.

Can you help reduce the time it takes to load my data set?

Here is a link to the stack overflow question. … 20-seconds


You can try to use smart rendering
You may also want to enable the static_background parameter in addition to smart rendering … onfig.html
Demo: … weaks.html

I have all of those options enabled already. They did not impact the time it took for the parse call to execute.

Ive solved this issue. The length of a project greatly slows down the load time. There were a few 100 year long projects. clamping down the project length to a reasonable time frame mitigates this load.


That’s some impressive planning:)
Could you please clarify, does such time frames come from the real use case (and we should look into possible optimizations for that use case), or was it just a glitch with the data?

We have use cases where 100 years is real, but in this case the fidelity is course., e.g tasks are a few months long. Will this be a problem for us?

it would depend on a combination of different settings,
but probably a step of planning you use in gantt will have the biggest impact - e.g. if you have 100 years between the start of the earliest tasks and the end of the latest task and allow a user to plan with a minute precision - this probably won’t work very good due to the current implementation. Gantt needs to iterate through the whole time grid and we haven’t planned it for such ranges.

I checked this demo … weaks.html
In this demo time step is 1 day and I’ve set time range from 2012 to 2113 and created 5000 tasks - everything seemed quite fast with this setup.
But you have to consider that this is a very light example. In real app it may work slower as you enable additional extensions, introduce custom logic, etc.

One more thing to consider is an overall width (in pixels) of the time scale. In IE browser the element size is limited to about 1.5 million pixels so you’ll have to keep overall scroll size below it (at least for IE users), currently we don’t have workaround for this

how about 100 years and using months as the lowest time slice?

As far as I can see now, there shouldn’t be any issues with such config.
100 year with 1-month step is only 1200 steps of the time scale - such amount won’t create any noticeable performance load.