Improve @expressions performance by pre processing sets

[joaquimg]

Description

This PR replaces #773 the improvement is the better performance in constructing JuMP @expressions.

This new PR only contains the set pre-processing from #773, so it is easier to review.

These set operations are performed more frequently than necessary. Pre-processing the sets before building expressions is more efficient as it requires strictly less work and allocations.

What type of PR is this? (check all applicable)

• Feature
• Bug Fix
• Documentation Update
• Code Refactor
• Performance Improvements

Related Tickets & Documents

Replaces #773

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and .md files under /docs/src have been updated if necessary.
• The latest changes on the target branch have been incorporated, so that any conflicts are taken care of before merging. This can be accomplished either by merging in the target branch (e.g. 'git merge develop') or by rebasing on top of the target branch (e.g. 'git rebase develop'). Please do not hesitate to reach out to the GenX development team if you need help with this.
• Code has been tested to ensure all functionality works as intended.
• CHANGELOG.md has been updated (if this is a 'notable' change).
• I consent to the release of this PR's code under the GNU General Public license.

How this can be tested

This should not alter any outputs.

Post-approval checklist for GenX core developers

After the PR is approved

• Check that the latest changes on the target branch are incorporated, either via merge or rebase
• Remember to squash and merge if incorporating into develop

[odow]

This might need double checking by the GenX developers to confirm they're okay with eGenerationByVRE being removed

[odow]

Is there a before/after benchmark?

[joaquimg]

The varaibility has been large but I got this for build times:
before:

[1.652069727, 1.788213802, 1.626290085, 1.669528328, 1.660131141, 1.68649478, 1.533541384, 1.535813091, 1.582190896, 1.569001761]
avg = 1.6303274994999999
9.40 M allocations: 620.638 MiB

after:

[1.400132035, 1.472891334, 1.421627804, 1.402612685, 1.546436285, 1.522128814, 1.417519068, 1.416916671, 1.547674436, 1.444814263]
avg = 1.4592753395
8.80 M allocations: 582.782 MiB

which is about a 12% improvement.

GC time is around 50% in both cases.

[odow]

I guess the full improvement is a bit more because of the changes in MutableArithmetics.

[joaquimg]

I guess the full improvement is a bit more because of the changes in MutableArithmetics.

Yup. I will double-check the number, including MA.