aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/js/RrdGraph.js
diff options
context:
space:
mode:
authorPeter Wu2014-07-26 12:31:15 +0200
committerPim van den Berg2014-08-02 12:29:50 +0200
commit5d21cdf8e8062f5cc3912c787dce685405a342b3 (patch)
tree3e2a92e1ff41a7c654070a6d228638460fb42183 /js/RrdGraph.js
parentjsrrdgraph: Remove unused getStringAt, move implementation (diff)
downloadapt-panopticon_cgp-5d21cdf8e8062f5cc3912c787dce685405a342b3.zip
apt-panopticon_cgp-5d21cdf8e8062f5cc3912c787dce685405a342b3.tar.gz
apt-panopticon_cgp-5d21cdf8e8062f5cc3912c787dce685405a342b3.tar.bz2
apt-panopticon_cgp-5d21cdf8e8062f5cc3912c787dce685405a342b3.tar.xz
jsrrdgraph: Use Typed Arrays for better performance
Profiling was done using Firebug in Firefox 31 on Linux x86_64. Test was performed as follows: - rrd generated using collectd with default rrdtool settings. - CPU utilization was visualized with 8 lines (idle, nice, etc.). - The data has gaps between 20% and 40% and 55% and 85% (were no data was collected). - The measured performance was from advancing the data 40% to the right (there are no gaps before that). The total running time is 18859.094ms (old), 5151.822ms (new). In the below profiles, common functions with similar running times and call counts were omitted. Columns in the profile table: function, call count, time spent in the function, average time spent per call in *total* (including other functions called by the function) and percentage of the total running time. The RrdGraph.data_calc function was not called much, but seems to be heavy enough to include in the trace. Profile for old implementation: - getEndianByteAt 246959 12200.42ms 0.063ms 64.69% - getDoubleAt 30306 3183.393ms 0.612ms 16.88% - RRDRRA.getEl 30306 1177.33ms 0.665ms 6.24% - RRDRRA.calc_idx 30306 449.201ms 0.015ms 2.38% - (RrdDataFile.build 47 431.986ms total=21189.434ms 2.29%) - getByteAt 254290 327.369ms 0.013ms 1.74% - (2 functions omitted) - getCStringAt 752 103.308ms 0.271ms 0.55% - RrdRpn.calc 5504 98.55ms 0.018ms 0.52% - (1 function omitted) - (RrdGraph.data_calc 1 75.417ms total=174.535ms 0.4%) - getLongAt 1128 65.796ms 0.212ms 0.35% Profile for new implementation: - RRDRRA.getEl 32280 1202.446ms 0.065ms 23.34% - RrdRpn.calc 43968 848.693ms 0.019ms 16.47% (probably includes the getByteAt call which is not visible in trace) - (RrdGraph.data calc 2 616.648ms total=1466.432ms 11.97%) - getDoubleAt 32280 460.894ms 0.014ms 8.95% - (RrdDataFile.build 48 438.1ms total=2719.07ms 8.5%) - (RRDRRA.calc_idx 32280 436.375ms total=436.375ms 8.47%) - (10 functions omitted) - getLongAt 1152 16.273ms 0.014ms 0.32% - (2 functions omitted) - getCStringAt 768 13.651ms 0.018ms 0.26% A second test was performed on a graph with no visible data points. I dragged it to the left to get in the future with only NaN values. Then the profile started. It turns out that the byte readings are not dominating here, 99% of the time was spent in RrdRpn.calc and RrdGraph.data_calc: - (old) RrdRpn.calc 3.14k 58493s 0.019ms - (new) RrdRpn.calc 3.10k 56912s 0.018ms - RrdGraph.data_calc (n=2) took about 46 seconds for both. - getByteAt (n=12096): 0.014ms (old), invisible/inlined (new) - getEndianByteAt (n=4608): 0.040ms (old only) - getCStringAt (n=768): 0.285ms (old), 0.018ms (new) - getLongAt (n=1152): 0.233ms (old), 0.014ms (new)
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions