Mute nested nodes via inputs for compositing performance

Preface: I know there is already a "Switch node" and "Menu Switch node", but

Compositing performance is not efficient at all in some ways, because the entire compositing pipeline is calculated with any change anywhere across the compositing workflow.

For example: If I have several nodes/effects connected to the first input of a Mix Color node and another series of nodes/effects connected to the second input of the Mix Color node.

If, I set the mix to 0.0 or 1.0 (essentially bypassing one of the 2 entire series of nodes) Blender calculates EVERYTHING.... then discards those necessary calculations anyway, since the mix is fully set to one or the other.

If the mix was anything in between, that would be necessary for the proper result, but when the mix is 0.0 or 1.0 (depending on blend mode, of course), it would produce the same result as if there wasn't even a Mix Color node, it should "know" this.

Also, if in a series from let's say node A to node F, if an adjustment/change is made at node E, again, Blender calculates everything...

If nothing has changed PREVIOUS to E, then nothing before E should be re-calculated.

I know that Blender's compositor doesn't have a smart caching implementation of any sort, which would be best for all performance issues (and would push Blenders compositor to an amazing level....) hint hint ...

In the mean time, (until developmental focus can be placed on the efficiency of intelligent compositing cache methods), when a node or node group is muted, no calculations are performed. Therefore, even if we could have some way to mute/unmute nodes INSIDE of a node group from the inputs exposed on the outside, we could literally have manual control of whether or not the compositor makes some unnecessary calculations, speeding up compositing performance when certain features of a node group are not going to be used.

Example: If I have a node group that is for applying various/multiple types of glare (Fog Glow, Bloom, Ghosts, etc.) in a custom way, and decide that for the current render, I will only be using Fog Glow and none of the other types. Let's say the node group is constructed in a way where all the types of glare can be used together and so they are each included or not included by sliders or a boolean inputs.

Currently, they would all be fully calculated even though most of those calculations would be dumped and not even used/necessary. But if by enabling/disabling the boolean inputs for example, it could also have an option that actually muted/unmuted whatever node it was internally linked to..

Boom... Instant performance gain.

And in very complex multi pass compositing pipelines this adds up fast.

And even if Blender later has a "smart caching" system for '"knowing" what and what not to re-calculate depending on where in the pipeline a change is made (again.. hint hint fingers crossed), being able to mute internal nodes of a node group would still be a huge benefit and help even more with performance.

Because, some sort of caching system would prevent unnecessary RE-calculations and the external control of internal muting would prevent unnecessary calculations in the first place.

This is my suggestion, and in my personal experience, I have had some pretty heavy and complex compositing workflows that would benefit tremendously even from this simple little feature (since I tend to have re-usable chunks of compositing features put together as node groups, but not all aspects are used in every situation.)

But this could also benefit shader node groups, geometery node groups, etc.

As for implementation, a simple additional input type (or sub-type) could be created that mutes/unmutes whatever node/node group is directly linked to it internally. Or perhaps just an additional selectable option (checkbox) of the input type.

Regardless of UI implementation, it would be a great feature.

Alternative suggestion: Optimized nodes that perform any mixing/blending so that whenever the result would be the same as if it was just passed through. (The switch node should also not have to calculate anything from ONE of it's inputs but only the other, whichever is actually being used. It is not optimized either, and although the description of the Menu Switch node states that "only the input that is passed through the node is computed", this cannot be true, because bypassing the menu switch and connecting the selected input directly results in much faster results than choosing it as an input from the menu, so it could be optimized as well.)