Profiling & Benchmarking
debt(d7/e3/b2/t5)
Closest to 'only careful code review or runtime testing' (d7). Absence of profiling is invisible to linters/SAST; Blackfire/Xdebug/Tideways from detection_hints reveal it only when someone actively measures performance. No automated tool flags 'this team optimises by intuition'.
Closest to 'simple parameterised fix' (e3). Per quick_fix, remediation is installing Blackfire/Xdebug profiling on staging and reading the flamegraph — a tooling setup task, not a code change. Slightly more than a one-line patch but well short of a refactor.
Closest to 'minimal commitment' (b1), nudged to b2. Profiling is a practice/tooling habit, not a structural choice baked into the codebase; applies_to spans web/cli/queue but imposes no ongoing maintenance tax once the tool is wired up.
Closest to 'notable trap most devs eventually learn' (t5). The misconception (microtime() timing is enough) is the canonical wrong belief — developers reliably guess that manual timing equals profiling, and miss that full call graphs expose unexpected hotspots. Also the production-overhead and dev-vs-prod-dataset gotchas listed in common_mistakes.
Also Known As
TL;DR
Explanation
Premature optimisation without profiling is guesswork — 90% of bottlenecks are typically in 10% of the code. PHP profiling tools include Xdebug (call graph, trace, memory profiling), Blackfire.io (production-grade performance management), Tideways, and SPX. Micro-benchmarking uses microtime(true) for targeted comparisons. Profile in a production-like environment — OPcache and real data change performance characteristics significantly. Focus first on I/O (database queries, HTTP requests) before CPU.
Common Misconception
Why It Matters
Common Mistakes
- Profiling in development with a different dataset than production — small datasets hide N+1 and index problems.
- Optimising based on code inspection rather than profiler output — intuition is wrong more often than not.
- Running the profiler in production without sampling — full profiling adds 10–100x overhead.
- Stopping after fixing the first bottleneck — fix one and profile again, the next bottleneck is now exposed.
Code Examples
// Guessing the bottleneck without profiling:
function slowReport(): array {
// Developer assumes the DB query is slow
// Adds caching around DB call
// Report still slow — actual bottleneck was CSV generation
// Profile first: Xdebug/Blackfire shows exactly where time is spent
}// Xdebug profiling — generates cachegrind files
; php.ini
xdebug.mode=profile
xdebug.output_dir=/tmp/xdebug
xdebug.profiler_output_name=cachegrind.out.%p
; Trigger on demand: XDEBUG_PROFILE=1 in query string or cookie
; Open output in KCacheGrind (Linux) or QCacheGrind (macOS/Windows)
// In-code micro-benchmark with hrtime (nanosecond precision)
$start = hrtime(true);
expensiveOperation();
$ms = (hrtime(true) - $start) / 1e6;
echo "Took {$ms}ms\n";
// SPX — lightweight always-on profiler for development
// composer require --dev reliforp/php-spx