Optimise cycling objects

[oliver-sanders]

Efficiency changes which reduce the memory and CPU impact of cycling objects:

• Avoid creating multiple parser instances.
• Move regex compilation out of the __init__ method.
• Slot classes.
• Minor fiddling with exclusions objects (@dvalters could you check these changes).

In combination with slotting of the isodatetime library (metomi/isodatetime#74) this reduces the resource requirements of suites with multiple sequences defined in the graphing.

The following results were obtained running cylc validate over the following suite varying the value of sequences:

[scheduling]
    initial cycle point = 2000
    spawn to max active cycle points = true
    max active cycle points = 5
    [[dependencies]]
{% for seq_no in range(sequences | default(10) | int) %}
    {% set minutes = seq_no % 60 %}
    {% set hours = ((seq_no / 60) | int) % 60 %}
        [[[R{{cycles | default(1)}}/+PT{{hours}}H{{minutes}}M]]]
            graph = task
{% endfor %}

I'll include this suite in the standard profile-battery tests in a future pull.
The impact on the runtime of the same suite:

The complex suite shows a small reduction in memory.

[matthewrmshin]

Looks good to me.

[hjoliver]

Nice result. Definitely include your new test suite in the profile-battery.

[hjoliver]

Looks good, just one question (out of curiosity).

[hjoliver]

What's the rationale behind this change? I would have thought set was better, with the need for membership testing below...

[hjoliver]

(this comment was meant to apply to self.exclusion_points)

[hjoliver]

OK, from a bit of googling, I guess set is implemented rather like dict, hence much higher memory consumption than list (makes sense)

[hjoliver]

(Answered my own question, will merge ...)

[oliver-sanders]

The reason I changed this is because an empty set is much larger than an empty list:

Size in bytes for collections of None elements:

elements	list	set
0	72	232
1	96	248
2	104	248
3	112	248
4	120	248
5	128	248
6	136	248
7	144	248
8	152	248
9	160	248

[dvalters]

This suite doesn't test effect on performance when exclusions are used, unless I'm missing something? (Although it tests 'empty'/no exclusions, which I suppose would be majority of the use cases?)

[oliver-sanders]

no exclusions, which I suppose would be majority of the use cases

The vast majority of sequence objects will not have exclusions. In these cases we have sequence.exclusions = [] so the memory impact is minimal and p_iso_exclusions doesn't even come into it.

The reason for changing to a set was to make exclusion objects a little slimmer - it's pretty marginal I'll admit but many of these changes are, a few bytes saved here, a few there.