Temporary fix to speed up canAvoidInstr

[DiligentPenguinn]

Following the fact that the check canAvoidInstr implemented in previous PR #1687 is too slow, this PR implements a temporary fix by caching the result of isEnvDependent as a field for each ControlItem

[coveralls]

Pull Request Test Coverage Report for Build 8881462669

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 29 of 30 (96.67%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.03%) to 82.112%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/cse-machine/utils.ts	18	19	94.74%

Totals
Change from base Build 8871900610:	0.03%
Covered Lines:	10930
Relevant Lines:	12966

---

💛 - Coveralls

[RichDom2185]

Looks good for a hotfix, thanks!

Though I'd remove isEnvDependent entirely and move the logic to the node creator function instead. What do you think? Do you foresee any more changes to this logic? You mentioned this is just a basic check (for the demo the other day) right? What future more "advanced" checks might there be?

Also, can I check what's left of this PR before it can be marked as ready?

Thanks!

[DiligentPenguinn]

@RichDom2185 Yes, I think that moving the logic to the node creator function is what should ultimately be done (for now this is just a basic, non-exhaustive check). but I won't be able to work on it very soon (due to exams). Until then I think it is still considerably slow with this fix though so I'm trying other ways to speed it up a bit more first. If you think it's fine for now then I'll mark it as ready

[DiligentPenguinn]

@RichDom2185 I just pushed a second approach, this seems to fix the efficiency issue, and I think it's closer to what would be done when we move the logic to the node creator function eventually.

[RichDom2185]

Just some minor nits, otherwise all good, thanks a lot!

[RichDom2185]

I'm good with this as long as it is a temporary hotfix. Please create an issue to migrate this to the node creator in the future.

Thanks!

[RichDom2185]

See #1702.

[RichDom2185]

Let's merge this first so that the other CI workflows can complete quickly…

[RichDom2185]

Part of #1698 (does not close it fully due to the comment above).