Optimize php -S Desktop runtime performance

[priethor]

Goal

Find out how much faster the Desktop Library workflow can get while staying on php -S.

The runtime comparison already showed that the custom static PHP bundle is still the best default: small bundle, one process, and solid single-endpoint latency. The problem now is the Library workflow. Hydrating several DataViews and opening a row is still around 3s p50 end to end.

Before we reopen a higher-maintenance worker runtime, squeeze the current setup and measure the result.

Scope

• Explore a few low-risk php -S optimization ideas against the current Desktop baseline:
  • persistent object cache
  • opcache.file_cache
  • opcache.preload
  • rebuilt PHP bundle with JIT, PCRE JIT, and APCu support
• Measure each change on its own before combining the useful ones.
• Reuse the existing benchmark scripts.

Out of scope

• Swapping to another runtime.
• Cortext plugin PHP or JS changes.
• Final packaging work: DMG, signing, notarization.

Acceptance criteria

• Each optimization has an engagement check proving it is actually active.
• The existing HTTP, Library workflow, and launch-to-shell benchmarks run for every useful variant.
• The Desktop app still launches, autologin works, data persists after restart, and the Desktop smoke test stays green.
• The final write-up records which optimizations stay, which ones do not, and the numbers behind the call.

Decision notes

Keep object cache if it gets the Library workflow under 1.5s p50, or close enough to be clearly worth it.

Keep opcache.file_cache if it improves cold start by more than 100ms.

Keep preload only if it still adds more than 5ms p50 after object cache and file cache.

Keep JIT only if it improves DataView endpoints by more than 5% and adds less than 300MB total RSS.

If the composed result still leaves the Library workflow above 1.5s p50, reopen the worker-runtime investigation with this better baseline.