[marius-bughiu]

Creating location-access activities takes the same process-wide lock even after their type prototype has been cached. Use a concurrent lookup for cache hits, retaining the existing lock and double check for first creation. Every call still creates a fresh activity with its own location reference; failures are retried.

Stack 1/4; base branch develop. Cumulative results start at public CoreWF commit 65caba7c7fc7d141e847775b00f2c9558e8daa59. None of these optimizations relies on duplicate expression text.

Measured on six synthetic authored cases with scenario-local variables and mostly unique expressions, with execution templates assigned versus removed. All validation and analyzer rules are enabled. Each of the five source-built CoreWF states ran twice per variant in forward/reverse order, serially on the same machine and compiler host. Every run deleted the isolated project .local first. The actual loaded CoreWF image hashes, input inventories, diagnostics and output coverage were verified.

Adjacent change (preceding stack state → this state; medians of two runs):

Metric	Templates	Before	After	Delta
Whole process	With	28 s	24 s	-3.57 s
Whole-process managed allocation	With	10.0 GB	9.9 GB	-38.25 MB
ValidateProject	With	2.76 s	2.34 s	-0.422 s
ValidateProject managed allocation	With	1.5 GB	1.5 GB	-28.15 MB
Peak sampled private memory	With	2.5 GB	2.5 GB	+20.56 MB
Whole process	Without	30 s	23 s	-6.68 s
Whole-process managed allocation	Without	9.6 GB	9.6 GB	+32.31 MB
ValidateProject	Without	3.39 s	2.28 s	-1.10 s
ValidateProject managed allocation	Without	1.5 GB	1.5 GB	+5.79 MB
Peak sampled private memory	Without	2.4 GB	2.3 GB	-103.69 MB

Whole-process observations behind the adjacent medians: With templates: before [28 s, 27 s], after [25 s, 23 s]. Without templates: before [26 s, 34 s], after [23 s, 24 s].

Cumulative change (original CoreWF state → this state; same cohort):

Metric	Templates	Before	After	Delta
Whole process	With	28 s	24 s	-3.57 s
Whole-process managed allocation	With	10.0 GB	9.9 GB	-38.25 MB
ValidateProject	With	2.76 s	2.34 s	-0.422 s
ValidateProject managed allocation	With	1.5 GB	1.5 GB	-28.15 MB
AnalyzeProject	With	4.18 s	3.32 s	-0.860 s
AnalyzeProject managed allocation	With	2.1 GB	2.1 GB	-0.615664 MB
Compile	With	15 s	13 s	-1.77 s
Compile managed allocation	With	5.7 GB	5.7 GB	-7.13 MB
Peak sampled private memory	With	2.5 GB	2.5 GB	+20.56 MB
Whole process	Without	30 s	23 s	-6.68 s
Whole-process managed allocation	Without	9.6 GB	9.6 GB	+32.31 MB
ValidateProject	Without	3.39 s	2.28 s	-1.10 s
ValidateProject managed allocation	Without	1.5 GB	1.5 GB	+5.79 MB
AnalyzeProject	Without	5.90 s	3.68 s	-2.23 s
AnalyzeProject managed allocation	Without	2.1 GB	2.1 GB	+2.48 MB
Compile	Without	15 s	13 s	-2.22 s
Compile managed allocation	Without	5.5 GB	5.5 GB	+24.35 MB
Peak sampled private memory	Without	2.4 GB	2.3 GB	-103.69 MB

Validation: 10 new behavior cases passed on the original and changed implementation, including concurrent first use, independent activity/location identity, and uncached failures. The 57 existing expression, validation and compiled-location serialization cases also passed. Release owner builds used SDK 8.0.426 and net6.0-windows; the compiler host used .NET 10.0.11. The complete CoreWF test suite was not run. Build copies disabled the repository's package-generation/global-cache-cleanup postbuild actions; no such project changes are included in this PR.

These are descriptive six-case diagnostics, not a 1,000-case throughput result or a statistical confidence claim. Host load, GC and run order can affect elapsed time; increases are retained in the tables. Managed allocation is not retained heap size. Nested phases overlap and must not be summed. Deltas use unrounded values; displayed values are rounded independently. Matching compiler output coverage does not establish arbitrary workflow execution or persistence equivalence.

Note

This change and description were prepared with AI assistance; the measurements and test results above were collected locally.