Make LoadEventPreNeXus faster

[Peter Peterson]

This is a continuation of #3224.

Profiling still says that the majority of the time spent is in processing the list rather than reading from disk by at least a factor of 100. The next big target is finding a better way of allocating memory in the individual event lists (via reserve) rather than just using the defaults and letting vector re-allocate memory as necessary.

[Janik Zikovsky]

I think the theory on how to do it is to split up the file in N small (but not too small) chunks and load them into separate EventWorkspaces which we will then merge into one big one.

Will probably require moving quite a bit of code around in the algorithm.

[Janik Zikovsky]

In [13642]:

Refs #3244: LoadEventPreNexus parallelized. Loading NOM_640 took 143 seconds (release mode) before, now takes about 46 seconds (for a 4 GB file).

[Janik Zikovsky]

In [13655]:

Refs #3244: Cached a few values to try to get the most speed possible in LoadEventPreNexus.

[Janik Zikovsky]

In [13658]:

Refs #3244: Fix test.

[Janik Zikovsky]

In [13659]:

Refs #3244: Fix segfault.

[Janik Zikovsky]

In [13662]:

Refs #3244: Fix segfaults for incorrect pixel IDs.

[Mathieu Doucet]

In [13670]:

Fix warnings. Re #3244

[Janik Zikovsky]

In [13700]:

Fixes #3244: Property for LoadEventPreNexus to automatically choose between serial/parallel loading for whichever case is fastest, based on the number of events to load.

[Peter Peterson]

It is faster.

[Stuart Campbell]

This ticket has been transferred to github issue ​4091