Measure performance issues 1.0

[DamienMosier]

Unfortunately with the previous singleton change, I only ran a handful of measures and noticed an ~60% gain. When running all of our measures I noticed some measures that relied heavily on the caching took a huge performance hit. These are the execution time on all of our measures/decks on the same build machine for our nightly runs.

Before the singleton updates when we still had Lazy variables.

ADD-E: Duration: 57m 4s
CRE: Duration: 1h 41m 27s
PND-E: Duration: 44m 15s
SPD: Duration: 9h 24m 18s

After singleton

ADD-E: Duration: 3h 32m 35s
CRE: Duration: 2h 46m 1s
PND-E: Duration: 10h 48m 39s
SPD: Duration: 3h 10m 21s

Here is the total run time of all measures on our build machine.

Latest 1.0 with singleton changes

I realized we needed an update to use scoped measures and singleton libraries. Here is the same run on our build machine with local changes in the engine to have both. No CQL changes were made to have a proper apples to apples comparison of the CQL performance.

ADD-E: Duration: 38m 0s
CRE: Duration: 57m 4s
PND-E: Duration: 53m 39s
SPD: Duration: 1h 36m 22s

As you can see, huge performance gains using singleton libraries to reduce the constructor initialization of all supporting libraries as well as improved performance to use caching/lazy variables inside the measure CQL to improve the performance when you write 1 CQL define that is used in multiple places, like a list of episode dates.