Cache identifier

[steve-the-edwards]

Avoid the class name lookup which happens on the identifier extension property getter each time currently.

Instead, when a Workflow is IdCacheable (as StatelessWorkflow and StatefulWorkflow are) we cache the identifier as cachedIdentifier and inline fetch this in the getter instead of computing it each time. We do this in StatefulWorkflow and StatelessWorkflow abstract classes using a lazy delegate that calls computeIdentifier (same impl as before). It's lazy in case we are an ImpostorWorkflow and we need our realIdentifier initialized before computeIdentifier is called.

[rjrjr]

If this pans out it will be a breaking change in a non-experimental interface, right? Wondering about proper SemVer treatment, wondering if we should provide a default implementation on the Workflow interface with a warning that it will be removed…

All of which is well out of scope for the PR, no reason to overthink things before we know it's a win.

[steve-the-edwards]

If this pans out it will be a breaking change in a non-experimental interface, right? Wondering about proper SemVer treatment, wondering if we should provide a default implementation on the Workflow interface with a warning that it will be removed…

All of which is well out of scope for the PR, no reason to overthink things before we know it's a win.

We could get around this with a bit more syntactic sugar. We could make the caching property internal and keep the existing .identifier extension property as something which just pulled out the value of that backing property (rather than computed each time).

[steve-the-edwards]

DNM: Note that we do not want to merge this until we determine its performance impact.

[steve-the-edwards]

If this pans out it will be a breaking change in a non-experimental interface, right? Wondering about proper SemVer treatment, wondering if we should provide a default implementation on the Workflow interface with a warning that it will be removed…
All of which is well out of scope for the PR, no reason to overthink things before we know it's a win.

We could get around this with a bit more syntactic sugar. We could make the caching property internal and keep the existing .identifier extension property as something which just pulled out the value of that backing property (rather than computed each time).

Nvm this. We do it with an extension interface IdCacheable so that we don't need to modify the existing public interfaces.

[steve-the-edwards]

Note that in our testing we did see a 28% improvement for the 'worst case' scenarios. No change to the median, but still a net positive.

[steve-the-edwards]

Abandoned in favour of #911