Measured against the selected medium inlining + omitted frame pointers tailcall build. Every PHP run uses OPcache, every candidate uses LTO, and compiler PGO is absent. JIT is disabled.

The two extra GCC flags do not establish a broad application improvement on this machine. Keep the selected baseline unless a representative workload demonstrates a repeatable gain. This is an exploratory comparison on a shared Ryzen 9 5950X host, not a guarantee for other CPUs or PHP builds.

Positive changes below mean higher throughput. PHPStan is expressed as reciprocal analysis time; PHPBench uses its official score; HTTP uses requests/second. Brackets are 95% paired bootstrap intervals.

Only two of these 20 intervals exclude zero: pointer analysis on the one-core worker post, and locality on the four-core worker post. Both gains are small, and the latter interval is unusually wide because of slow baseline samples. These intervals are not corrected for multiple comparisons. Neither flag reliably improves PHPStan or PHPBench.

All 36 timed PHPStan analyses returned zero errors and their 72 parent/worker runtime probes confirmed OPcache enabled and JIT disabled. All 18 official PHPBench runs completed 56 subtests. HTTP samples passed page-content, loaded-library, worker-runtime and OPcache checks.

The baseline is:

-flto -falign-functions=64 -fomit-frame-pointer
--param=inline-unit-growth=100
--param=ipa-cp-unit-growth=100
--param=large-function-growth=500
--param=max-inline-insns-auto=250
--param=max-inline-insns-single=500

Each candidate adds exactly one flag, in compilation and in the actual libtool-driven LTO link. The locality option groups call chains; GCC recommends profile feedback for it. Pointer analysis is disabled by default and can increase compilation resource usage. See the GCC optimization reference.

These are single build times, not repeated compile-speed measurements. Neither new candidate caused a large observed build-cost increase here. Each passed 432 PHP correctness tests, with one skipped because zend_test is not built; there were no failures or warnings.

The original 16-workload shared-library matrix has descriptive geometric-mean throughput gains of 0.92% for locality and 0.71% for pointer analysis. The initial CLI matrix was noisier. Five CLI workloads exceeded the 3% median-absolute-deviation threshold for at least one variant and were repeated with 18 samples each and a longer calibration target. No shared-library workload crossed that threshold. Both batches remain in the raw archive.

The repeat table shows elapsed-time changes; negative is faster. Brackets are 95% paired bootstrap intervals.

Fibonacci does not support the initial 19% CLI regression: the longer repeat is +2.61% for locality and −0.56% for pointer analysis. Shared-library Fibonacci was −1.32% for locality and +1.30% for pointer analysis in the original, steadier matrix. The two SAPIs have different final code layouts. Their differing outcomes are another reason to test the actual shared library used by FrankenPHP.

The main repeatable synthetic gain is exception handling: locality improves the initial CLI timing by about 8% and shared-library timing by about 6%. The CLI counter pass also shows fewer cycles with nearly unchanged instruction count. Pointer analysis retains a small Mandelbrot regression in the longer CLI repeat. These component effects do not establish an application-wide win.

The original table reports elapsed-time changes and includes the noisy observations; use the repeat table above for the five repeated CLI cases.

The separate perf stat pass contains three measured samples per variant per case, interleaved after a discarded warmup. It covers all 16 CLI workloads, all 16 shared-library workloads, PHPStan, the exact PHPBench payload (-i 2000000), and both Symfony routes/modes at one and four cores. There are 378 measured counter samples. Microbenchmark counters cover the whole process, including startup, setup and the four internal warmup calls; their scope is wider than the internal PHP timer. The PHPBench counter pass excludes the PTS controller. PHPStan includes its inherited analysis worker. HTTP counters attach only to the benchmark server PID, including its threads, and use an acknowledged enable/disable window around wrk. Counts are divided by completed requests.

All six hardware events reported 100% running time: cycles, instructions, branches, branch misses, generic cache references and generic cache misses. L1 instruction-cache and instruction-TLB miss probes returned “not counted” and were excluded. Generic cache events must not be interpreted as specific instruction-cache events. These are the guest-visible counters of a WSL2 virtual PMU.

The HTTP counter batches are slower and substantially more variable than the separate timing batches. The counter pass provides execution counts; the separate unprofiled batch supplies the headline throughput estimate. Some four-core cycle medians are dominated by slow samples; their large changes below are retained, not treated as reliable flag effects. Each cell gives instruction change / cycle change / branch-miss change, in percent, relative to medium + omit FP. Negative means fewer events.

The useful broad observation is that neither flag materially reduces PHP instruction work: PHPStan and PHPBench instruction changes are within about 0.13%, and the one-core HTTP changes within about 0.3%. The CLI exception case shows a larger cycle reduction for locality, consistent with its timing improvement, despite almost unchanged instructions. This does not identify a specific cache or branch mechanism.

The user-filtered software context-switch event reported zeros even when /proc showed switches, so those zeros are not used as evidence of an idle host. HTTP data additionally stores per-thread /proc context-switch snapshots and deltas. CLI/application data stores getrusage context-switch and CPU-time deltas for the process tree, including the perf launcher. Raw counters, event running times, individual observations and all derived ratios are retained.

The following absolute medians give the counter changes scale. IPC and miss rates here are ratios of the displayed counter medians.

CLI Mandelbrot’s branch-miss rate changes from 0.128% at baseline to 1.200% with pointer analysis. This is consistent with its small repeated timing regression, but these observations alone do not isolate why branch prediction changed.

BOLT is technically usable on this GCC/LTO shared PHP library. This experiment uses LLVM BOLT 21.1.8 from the official LLVM Debian packages, extracted locally. No compiler PGO was used; GCC was not rebuilt with profile-use flags. BOLT has its own execution profile, collected from an instrumented copy of the final library.

The three comparison builds are the selected baseline, a prepared control adding -fno-reorder-blocks-and-partition and link-time -Wl,--emit-relocs, and BOLT's rewrite of that exact prepared library. The control matters because its compiler flag changes code layout before BOLT runs. All three remain GCC tailcall/LTO builds with medium inlining and omitted frame pointers. PHPStan runs through the same small shared-library CLI launcher for all three; its absolute times should not be compared directly with the preceding standalone-CLI PHPStan batch.

The host does not expose branch-stack sampling. An instrumented library instead trained on the two Symfony routes in classic and worker modes, on one core with OPcache enabled and JIT disabled. BOLT's periodic profile dump was needed for the shared library; its helper process was cleaned up with the benchmark server's own process group. The retained profile is the accumulated dump from the final server process in each mode, merged across the two modes. Earlier training processes are not included. PHPStan was held out of training.

The rewrite uses:

-reorder-blocks=ext-tsp -reorder-functions=cdsort
-split-functions -split-all-cold -split-eh
-align-functions=64 -align-functions-max-bytes=64
-dyno-stats -update-debug-sections -no-threads

The official BOLT guide documents shared-library support, retained relocations, the GCC block-partitioning constraint and profiling choices. Exact build, instrumentation, merge and rewrite commands, tool/package hashes and profiles are archived with this study.

BOLT found a nonempty profile for 920 of 15,322 functions; 28 profiled functions could not be optimized. It reordered blocks in 731 functions. The log reports a 100% call-graph flow conservation gap, even though its CFG discontinuity and CFG flow gaps are zero. This profile-quality limitation is retained in the evidence rather than presented as an ideal profile. BOLT also warned about 409 unanalyzed relocations, a make_fcontext frame-description conflict, a cold function from a static dependency, and unsupported DWARF encodings/forms. Passing tests do not establish complete native unwind/debug-info fidelity.

The prepared control and rewritten library each passed 432 correctness tests with one zend_test-dependent skip and no failures or warnings from the PHP test harness. All measured PHPStan analyses and HTTP response/runtime checks passed. This is an exploratory local result, not a production validation of arbitrary extensions or native debugging tools.

The timed BOLT comparison uses six interleaved samples per variant for PHPStan and each of the four one-core HTTP cases. Hardware counters use a separate three-sample pass. Keeping perf out of the timing pass avoids using its visibly perturbed HTTP throughput as the speed estimate. Four-core BOLT and retraining on additional applications were not measured.

Positive changes are throughput gains; brackets are 95% paired bootstrap intervals. “Rewrite vs control” isolates BOLT from its preparation flags.

Absolute medians from this interleaved batch:

The separate hardware-counter pass reports instruction / cycle / branch-miss changes in percent. HTTP counters are per completed request.

The BOLT rewrite does not demonstrate a reliable speedup in this experiment. Relative to the prepared control, the medians are −0.50% for PHPStan, effectively unchanged for classic blog, +0.96% for classic post, −0.74% for worker blog and +2.10% for worker post. Every one of those intervals includes zero. The complete BOLT build is 1.55% slower than the original on held-out PHPStan, but the rewrite/control comparison does not isolate a statistically clear BOLT penalty.

The wide HTTP intervals leave room for small gains or losses. This result supports keeping the selected compiler profile, not asserting that BOLT can never help PHP. Better representative training, investigation of the reported profile-quality/relocation warnings and measurements on a quieter native host would be needed to establish an advantage beyond this experiment. This run does not establish globally optimal BOLT settings.

All three primary variants use PHP commit aefec40ab2f4858bf2abf8cef707837d3e0315c8, GCC 16.2.0, ZTS, x86-64-v3, -O3, LTO, 64-byte function alignment, medium inlining and omitted frame pointers. The baseline is the selected medium+omit-FP build. Each candidate appends exactly one flag. Compiler PGO, JIT and fast-math are absent. OPcache and its normal optimizer are enabled in every PHP invocation, including controllers and spawned workers.

Medium means inline-unit-growth=100, ipa-cp-unit-growth=100, large-function-growth=500, max-inline-insns-auto=250 and max-inline-insns-single=500. All five parameters and the candidate flag are forwarded through libtool at LTO link time. Build metadata preserves the actual shared-library link and object LTO options.

CLI/shared microbenchmarks use 12 samples per variant per workload with two discarded warmups. PHPStan uses 12 analyses per variant with two warmups; its result cache is removed outside the timer. PHPBench uses six official PTS runs per variant with one warmup and all 56 PHPBench subtests. Symfony HTTP uses nine blocks on one core and six on four cores: blog and post, classic and worker. Each route gets a one-second warmup and a four-second measurement. CLI work is pinned to CPU 4; four-core HTTP uses CPUs 4,6,8,10; HTTP clients use 16,18. All matrices run sequentially, without compilation or BOLT processing in the background.

The host is a shared Ryzen 9 5950X WSL2 machine. Background activity produced visible CPU waiting in some initial CLI samples. Repeat selection is based only on dispersion: rerun every workload where any variant has median absolute deviation above 3% of its median, retaining the original observations. Repeat runs use 18 samples and a longer 0.4-second calibration target. Shared-library measurements did not cross that threshold.

Intervals resample paired blocks 5,000 times and use the 2.5th/97.5th percentiles. They are unadjusted for multiple comparisons; small isolated wins across this many workloads should not be treated as universal improvements. Geometric means across synthetic workloads are descriptive, without an overall confidence interval.

Symfony Demo, dependencies, fixture database, assets, FrankenPHP executable and wrk are reused unchanged from the preceding study. All are fingerprinted in the raw results. Production logging suppresses PHP 8.6 deprecations to prevent logging from dominating the benchmark. The recorded ZTS OPcache memory-status issue remains unchanged; cached scripts and cache operation are verified, but invalid reported memory fields are not used for conclusions.

The study contains 1,746 unprofiled timing samples (including the 270 noise-selected repeats and 90 BOLT comparison samples), 423 separate measured counter samples, and 432 passing correctness tests for each of four new libraries. Warmups, BOLT training requests and runtime probes are additional and are not counted as performance samples.

The artifact manifest gives sizes and SHA-256 hashes. All *.json.gz files are ordinary gzip-compressed JSON:

• Primary analysis, CLI timings, shared-library timings, and longer CLI repeats.
• PHPStan, official PTS PHPBench, one-core HTTP and four-core HTTP.
• Counter analysis, CLI counters, shared-library counters, PHPStan counters, PHPBench counters, one-core HTTP counters and four-core HTTP counters.
• BOLT analysis, BOLT PHPStan timings, BOLT HTTP timings, BOLT PHPStan counters and BOLT HTTP counters.
• GCC build metadata, BOLT build metadata, BOLT rewrite log, GCC correctness, BOLT correctness and final validation.
• Source/command/profile archive: frozen timing runners, current counter runners, orchestration and analysis scripts, commands, profile data and tool evidence. The scripts record absolute paths from this machine; adapt those paths when reproducing elsewhere. Rebuilding also requires the recorded PHP/dependency/FrankenPHP environment. Compiled binaries are not copied into the repository.

The reusable counter entry points are perf-workloads.py, which takes a completed micro/application result as its input, and benchmark-frankenphp.py --perf, which measures server threads around the load window. A timing run and its counter run should use different output paths and run sequentially. The parser retains unavailable events, raw counts and running percentages; required cycle/instruction events must be available. perf's control protocol provides the acknowledged measurement window.

The selected production profile remains medium inlining + omitted frame pointers + LTO, with 64-byte function alignment for the x86-64 GCC tailcall VM. This study does not add locality, pointer analysis or BOLT to package defaults. See the preceding compiler-flag study and the earlier hybrid/tailcall comparison for how the baseline was selected. SPC_CMD_VAR_PHP_MAKE_EXTRA_LDFLAGS_LIBPHP is additive to the general PHP linker flags; those flags already carry the PHP optimization settings through libtool, so duplicating them is unnecessary.