Benchmark then Parallelise ConvertToReflectometryQ

[Owen Arnold]

There is currently no performance tests watching ConvertToReflectometryQ. While this algorithm runs quickly (currently) on the example datasets I have, we want to improve performance, and in no way hinder it.

The point of this ticket is to:

• Peformance Test ConvertToReflectometryQ (could be tricky given the difficulty in generating an instrument of this complexity at runtime)
• Make attempts to improve the speed of this algorithm (see below).

The current implementation of ConvertToReflectometryQ does not take advantage of some of the parallel processing options available. We can get things running quicker if we do this.

In general, the Reflectometry datasets do not get particularly large, so this is not high-priority work.

[Owen Arnold]

refs #5457. Add perf test

Changeset: 82b763b4071ad637f140bc2aa4888538c1beb41f

[Owen Arnold]

refs #5457. fix perf test

Changeset: 7038ba52351d9bce2bc712884720ed55b169e672

[Owen Arnold]

I've done some benchmarking now that I have the performance test, and I'm finding that the algorithm is slower when box splitting is parallel, then when not. This is probably due to the overhead of setting up the thread pool compared to the size of the data, but the data used in this test is representative.

Algorithm runtime without parallel splitting ~0.3 s Algorithm runtime with parallel splitting ~0.5 s

I'm therefore not going to enable the thread pool for this algorithm.

[Owen Arnold]

refs #5457. Add perf test

Changeset: 82b763b4071ad637f140bc2aa4888538c1beb41f

[Owen Arnold]

refs #5457. fix perf test

Changeset: 7038ba52351d9bce2bc712884720ed55b169e672

[Michael Reuter]

This is a good example of doing benchmarking before making improvements. Sometimes the improvements don't really work.

[Stuart Campbell]

This ticket has been transferred to github issue ​6303