Performance

This page is for discussing performance considerations. See also:

• Performance with Coniql
• Performance Check with Profiler
• Performance improvements

Summary

The target update rate is 10 Hz, an allocation of 100ms per update.

• If we render about 100 simple readbacks, it takes about 100 ms for the render to complete.
  • For a single readback, it takes about 10 ms. For a single readback containing a large array (but not rendering it all), more like 25 ms.
• If we send a waveform of about 100,000 points over a GraphQL subscription, we can maintain a rate of 10 Hz. It becomes more difficult at 1,000,000 points.
  • Note: the maximum number of pixels that you might render on a screen is about a million. If we are plotting a million points at 10 Hz then we are almost certainly being inefficient.
  • Note: a million points at 10 Hz might be 80 MB/s, not a realistic amount of data to manage anyway
• Pages are currently loading at a comparable rate to CS-Studio, but without the start-up overhead from CS-Studio.

What is fast enough?

If cs-web-proto is as fast as pre-existing java-based tools then it can replace these tools. It is generally accepted that control system screens are not required to update faster than 10 Hz.

Text updates

• I think 500 scalar PVs at 10 Hz using 10% of a CPU is clearly good enough.

Plots

• The Diagnostics summary screen has a 2D plot of a PV with 196608 DBR_CHAR elements updating at 5 Hz (about 1 MB/s)
• For PVs with more than 1e6 elements we expect to encode in a video stream

Data throughput

How fast do we need to get data into the browser over GraphQL? I suggest 5000x float PVs at 10Hz and 50x 100000 element float waveforms at 10Hz.

See also Performance with Coniql, which suggests that we can transfer arrays of 1e5 elements at 10 Hz, but that 1e6 elements is more of a challenge.

Page loading

I suggest an initial page load time of less than 5 seconds, and subsequent page loads of less than 2 seconds are good aims.

Other

Animations and screen updating should never make the mouse pointer lag, and click responses should feel instant. Not sure how to measure these...

Comparisons

This paper was an attempt to measure performance of different EPICS UIs. That paper used a Soft IOC with 500 PVs iterating from 0-99 at 10 Hz. The IOC was run locally on the machine to remove the effects of network variations. Other resources from the paper can be found here: http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/html/sessi0n.htm (TUMIB10).

It would be interesting to replicate this setup with EDM, CS-Studio and CS-Web-Proto, first using local PVs and then channel access and PVAccess.

Performance-related resources

See the following pages for performance related investigations with plenty of flame graphs and mishaps which I have been learning from:

• React Performance Primer
• Breakdown of the available tools
• Optimizing React in practice
• Things which are always hard in React
• the about:performance tab in Firefox gives limited information about the performance of different tabs

Why Did You Render

This is a useful tool for determining why a component has rendered. The documentation is quite straight-forward.

To set it up in App.tsx using ES6 modules:

import whyDidYouRender from "@welldone-software/why-did-you-render";
whyDidYouRender(React);

I had to set a particular setting for the results to show up in the console:

PVWidget.whyDidYouRender = {
  logOnDifferentValues: true
};