Can adaptive execution retain most of the earlier repeated-input latency benefit while memory, specialisation and loading cost scale with active reusable regions rather than the number of generated strategies?
Success was deliberately not a fixed speed ratio. It required correctness plus evidence that physical residency tracked the active canonical set under tight budgets.
CLIP used openai/clip-vit-base-patch32 with named image, token and attention-mask inputs. EfficientSAM used the pinned vit_t implementation with image, point-coordinate and point-label inputs. Both produced 17-strategy portfolios automatically from graph dependencies.
The final CLIP mixed trace contains 60 requests and uses 5 warm-up requests; the final EfficientSAM prompt-heavy trace contains 30 requests and uses 3 warm-up requests. All forced counterfactuals ran serially in separate processes. The evidence retains the complete latency samples and selection records used for summary statistics.
For each practical and tight logical budget the harness records:
- steady p50, p95 and mean latency;
- first-use and named-function load/specialisation latency;
- process lifetime peak RSS and RSS after the trace;
- loaded-function count, loads and evictions;
- retained cache bytes, hits, misses and hit rate;
- selected strategy counts and change masks;
- forced-strategy counterfactuals and strategy regret.
Process peak is the OS lifetime high-water value, not the maximum periodic sample. Reported GB values are decimal; exact bytes are canonical. The frequently used “14.4 GiB” shorthand is imprecise: 14,456,012,800 bytes is 14.456 GB or 13.464 GiB.
| Model | Adaptive p50 / p95 / mean | Packaged monolith p50 / p95 / mean | Peak RSS | Live peak |
|---|---|---|---|---|
| CLIP | 12.446 / 23.895 / 13.760 ms | 11.252 / 14.190 / 11.678 ms | 14,456,012,800 B | 3 |
| EfficientSAM | 45.694 / 168.552 / 59.212 ms | 156.661 / 171.035 / 157.873 ms | 1,814,806,528 B | 3 |
All 17 strategies for both models were bit-exact. CLIP's adaptive selector was slower than its packaged monolith at all three aggregate latency measures. EfficientSAM beat its packaged monolith but not the 31.319 ms manual cached-image reference; it roughly matched the 47.067 ms seeded automatic path.
Before architectural changes, the unchanged implementation was snapshotted, hashed and rerun:
| Model | Eager portfolio | Process peak / RSS after | Positive repeated-input reference |
|---|---|---|---|
| CLIP | 17 strategies / 28 functions | 14,405,255,168 / 6,692,192,256 B | fixed-image 5.938 ms vs 11.293 ms monolith; fixed-text 8.543 ms vs 11.406 ms |
| EfficientSAM | 17 strategies / 28 functions | 2,405,924,864 / 2,282,848,256 B | manual cached-image 31.319 ms; seeded automatic 47.067 ms; official monolith 87.805 ms |
The compiler and exactness mechanism succeeded. The general runtime did not. Correct pruning preserved the full plan portfolio, and Core AI did not expose a way to make physical memory follow the three live handles. EfficientSAM's model-specific improvement is real but insufficient evidence for a general system.
The compact source data are in evidence; regeneration constraints are in reproducibility.