You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently generated line series path starts d="M 0 50.901274125000015 L 1.0833991737205007 35.40761640000001..." and it could be enough to have d="M 0 50 L 1 35..."
I have absolutely no need for multiple decimal points in path definition and I'm not really sure when and why would someone need subpixel resolution.
So, I was thinking about a chart parameter, pathPrecision that would allow controlling how is the path generated, something like coordinate.toFixed(pathPrecision) or Math.round(coordinate)
In my case, where I display over 20 series at 1500+ points, each series can be shortened by half from 30k characters to around 15k characters. At 20+ series that is 300k HTML characters less.
I've created a benchmark to test ( JsBench ) if there would be any benefit at the level of path generation and
it could provide almost 65% performance gain.
I don't know how to measure browser performance in response to shorter path definition, since I'm mostly working in C#.
I hope that JS level performance gain is worth your attention.
Background:
I'm using ApexCharts to display display 20+ series of 2+mln points each.
To optimize it and allow for fast scrolling I control it at the level of input data, not the chart (specifically I work with Blazor Apex Charts - but I don't think it matters here).
Every time I scroll the brush chart or zoom/select main chart, I filter the dataset and pass it to the chart to display only 1point per pixel.
I started looking at the performance after it obviously froze when I threw at it 65 mln points 😆. First thing that I've noticed was the number format of points in path which obviously wasn't the problem 😆
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Background of how I'm using the chart at the end.
Currently generated line series path starts d="M 0 50.901274125000015 L 1.0833991737205007 35.40761640000001..." and it could be enough to have d="M 0 50 L 1 35..."
I have absolutely no need for multiple decimal points in path definition and I'm not really sure when and why would someone need subpixel resolution.
So, I was thinking about a chart parameter, pathPrecision that would allow controlling how is the path generated, something like coordinate.toFixed(pathPrecision) or Math.round(coordinate)
In my case, where I display over 20 series at 1500+ points, each series can be shortened by half from 30k characters to around 15k characters. At 20+ series that is 300k HTML characters less.
I've created a benchmark to test ( JsBench ) if there would be any benefit at the level of path generation and
it could provide almost 65% performance gain.
I don't know how to measure browser performance in response to shorter path definition, since I'm mostly working in C#.
I hope that JS level performance gain is worth your attention.
Background:
I'm using ApexCharts to display display 20+ series of 2+mln points each.
To optimize it and allow for fast scrolling I control it at the level of input data, not the chart (specifically I work with Blazor Apex Charts - but I don't think it matters here).
Every time I scroll the brush chart or zoom/select main chart, I filter the dataset and pass it to the chart to display only 1point per pixel.
I started looking at the performance after it obviously froze when I threw at it 65 mln points 😆. First thing that I've noticed was the number format of points in path which obviously wasn't the problem 😆
Beta Was this translation helpful? Give feedback.
All reactions