Automattic / Automattic/cortext
Optimize php -S Desktop runtime performance
- Dominant language
- JavaScript
- Stars
- 51
- Forks
- 2
- Avg merge
- 3h 12m
- Merged PRs (30d)
- 8
Description
## 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.
Contributor guide
Research direction
Start by locating the current Desktop baseline and existing HTTP, Library workflow, launch-to-shell, and smoke-test benchmark scripts, then run the baseline. Measure each listed php -S optimization independently with engagement checks, verify launch, autologin, persistence, and smoke-test behavior, and record the numbers and keep/drop decisions in the final write-up.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- desktop, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100