charts.timeline performance limits

I’m trying out the timeline widget in the charts add-on. With a limited amount of points, everything is working quite nicely. But if I scale up to my actual use case the UI become so slow that it’s not useable anymore. The problem seems to be at client side, the execution of javascript. My test use case has 16 graph lines, with about 1000 data points each and 5 new data points/graph line added every 10s.

Is this just too many data points to ask timeline (or any javascript graph tool?) to handle or are there settings which might make it work? Anybody got some experience plotting data sets of this size or bigger in Vaadin/javascript?

Asking the Timeline to render 16000+ points each 10 seconds sounds like an awful lot of points to continuously render.

However, the problem you are experiencing is not so much the amount of points in the graphs (the timeline will optimize out the points not seen in the graph) but more likely caused by the amount of graphs you are trying to render.

Depending of what browser you use usually for each graph you add you double the rendering time. If you are stacking the graphs on top of each other it can be even worse, since each graph effect the other. Also the graph type effects the rendering speed, a line graph is usually faster to render than a bar chart and turning off graph shadows and fill colors will also improve the speed.

A couple of things I can think of that might effect the rendering for you:

Ensure you are not switching container data sources every time you update the graph with new points. Every time you add/remove a graph the Timeline will need to reload the already loaded points from the server. Instead just use the container addItem/removeItem API to add the points with.
Check if the advanced reducing alghorithm works better with your dataset than the default one (it has a memory penalty though) -

If possible reduce the amount of graphs shown in the Timeline (is it really essential that all 16 graphs are shown simultaneously or could they be toggled instead?)
Ensure the client cache is turned on -

Turn off graph shadows -

Turn off graph caps -

Do not use a fill color for your graphs (especially if you are drawing line charts)

Finally it when you have a lot of points you will usually need a lazy container to not keep every point in memory. This however usually have a bit of a performance penalty due to the lazy fetching of the points and will show up as a slow loading of the graphs.

Thanks! I’ll try those options and then see how many lines I can show concurrently.

I’m using VTimeLine to display dynamic IO performance charts.
The chart display 3 graphs, each can contain ~11K points.
When the limitation is reached we remove some old points from each graph.

We see that both chrome and ie11 browsers memory consumption continue to grow even though the number of the points in the charts reaches 11K and stays there.
After seeing this post mentioning the client cache, I has a look a the source and from first look I see that points are only added to the cache , never removed.
Can this be the cause?
I’m using vaadin 6.8.10, vaadin charts 1.1.8.

Hi Gili,

It sounds like that might very well be the issue in your case. Could you please create a ticket for the issue?

If you want to expedite a fix for this, you can use the Bug Fix Priority feature of our support subscriptions or support hours to get the issue fixed as soon as possible.


Thanks for the fast reply.
I’m now trying a run with client cache disabled to see if it solves the memory issue.
I’ve created a ticket:

I dont think I’ll post a fix for this since it will require some further knowledge of the cache logics

disabling client cache didn’t solve the issue.