CSSTUDIO-3420 Performance improvements to the Waterfall Plot widget

[abrahamwolk]

This pull request implements performance improvements to the Waterfall Plot widget:

1. This pull request changes the representation of the data received from waveform PVs from using a TreeMap with manual synchronization (which seems to have had a bug, and was apparently not working as intended!) to instead using a ConcurrentSkipListMap, with the consequence that manual synchronization is no longer needed (since the necessary synchronization is instead handled by the data structure).
2. Instead of using a LinkedList (with random-accesses taking linear time) to represent waveform data, ArrayList is used so that random-accesses take constant time.
3. The type of pvNameToInstantToValue was also changed from LinkedList to ArrayList, but this probably doesn't have a noticeable effect for practical use cases, where the number of PVs is expected to be small.

[kasemir]

ArrayList<Double> should indeed be better than LinkedList<Double>.
Maybe you can further optimize by avoiding the auto boxing between Double and double.
Conceptually, you want an ArrayList<double>.
See org.csstudio.javafx.rtplot.internal.util.IntList for a related ArrayList<int>.

[abrahamwolk]

@kasemir Thanks for the tip!

[georgweiss]

@kasemir, org.csstudio.javafx.rtplot.internal.util.IntList performs array copy (unless the initial size does not change). Is that more efficient than auto boxing?

[abrahamwolk]

@georgweiss In the best case (which, e.g., is the case in this pull request), the size is known in advance. However, the copying is usually not a problem since it occurs relatively seldomly: suppose an array is initialized with size 1, and that 2^n values are written to it. Then the number N of write operations to arrays is (including the copying):

N = 1 + 2 + 4 + 8 + 16 + ... + 2^n = 2*2^n - 1

If the size is known in advance, then the number of write operations is 2^n. Therefore, by using this strategy, the number of write operations to arrays is only doubled in comparison to the case where the size is known in advance.

[georgweiss]

@abrahamwolk, if the size is known in advance and does not change, why not use int[] or double[]?

[abrahamwolk]

@georgweiss I think it would be possible to use double[]. Readability and maintainability of the code is increased with higher-level abstractions, however.

[georgweiss]

If efficiency is of importance, then I think readability would be a cheap price to pay. For reference: for Android Google recommends arrays (primitives or objects) over higher level abstractions where possible.

[abrahamwolk]

I think it's certainly a possible optimization, and I think it's plausible that it may turn out to be a good optimization to implement. However, there may be other optimizations also, and at this stage I prefer to focus on higher level optimizations.

I see it as a trade-off between readability, maintainability, and the ability to modify the code on the one hand, and efficiency on the other hand. In particular, implementing lower level optimizations may make it more difficult to implement higher level optimizations, and for this reason I think that it is good to first focus on the high-level abstractions. If performance is still an issue after the high-level structure is optimized, then I think one should consider low-level optimizations.