About ElephantPHP

Why this site exists

Most PHP writing stops at the API surface. It names the function and its return value, then stops where the engine’s behavior starts — what the call compiles to, what the abstraction over it costs, and how the arrangement holds up under a day of production traffic. That layer is what this site is written for.

The goal is a specific one: articles that are still correct in three years, and that answer the question a colleague actually asks, which is not “how do I use this” but “why is it slow.” A post about a release is out of date the month it ships. A post about why the engine spends its time where it does outlives the version number in its examples, so the archive is built out of mechanisms rather than release notes.

The site follows one rule, and everything else here follows from it: explain the mechanism, then give the advice. Advice that arrives before the mechanism is a rule you have to trust, while advice that arrives after it is a conclusion you can check, disagree with, and apply to a case the article never mentioned. The aim is not to be believed. It is to hand you enough of the machinery that believing is unnecessary.

The author

That rule is a claim about whoever applies it, so the next thing to state is who does. Alden Pike writes about PHP, backend engineering, and the systems behind modern PHP applications. His work focuses on understanding what happens beneath frameworks and abstractions, from language internals and performance to architecture and production behavior. He prefers measurements over assumptions and trade-offs over universal rules. He writes at ElephantPHP. In practice the working material is opcode dumps and zval layouts, FPM pool arithmetic against a resident set that grows over a shift, and the gap between what a profiler attributes to a function and what the engine was doing inside it.

The measurement rig is fixed across the archive rather than chosen per post, which is what makes the numbers in one article comparable to the numbers in another: PHP 8.5.x, NTS, arm64, a Homebrew build on an Apple M4 Pro with 24 GB and 12 logical cores, not quiesced. Timing is taken with hrtime() inside the process, runs are interleaved rather than batched, warmup rounds are discarded, medians are reported with their ranges, and the effective configuration is printed by the same script that produced the figures. When a post runs on different hardware, it says so in its Method section, because a silent change of rig makes every cross-post comparison in the archive wrong.

What gets published, and what does not

One person’s interests are not a standard. Posts fall into five areas, and a draft that fits none of them does not belong here. Internals covers the engine: compilation, the Zend VM, memory layout, and the data structures behind the values you pass around. Performance covers measurement — profiling, benchmark method, and optimization that arrives with a number attached rather than an adjective. Architecture covers how an application is put together: boundaries, dependency injection, layering, and what a framework’s design decisions cost you three years later. Runtime covers production behavior: PHP-FPM pools, worker processes, long-running runtimes, and where memory goes over a day of traffic. Ecosystem covers the tooling and the standards around the language: Composer, static analysis, and the PSRs.

The list of what does not get published is shorter and firmer. No news and no release-note recaps. No beginner tutorials and no copy-paste snippet posts — the reader this site assumes already ships production code and reads framework documentation fluently. No numbered listicles, no framework marketing, and no post that recommends something without stating what it costs and the conditions under which the cost is worth paying.

Two commitments are worth holding this site to. Every performance claim carries a number and the method that produced it, or it says plainly that the thing was not measured. “Faster” without a figure is an opinion, and a benchmark that does not state its method is an opinion with digits. Nothing published here is paid for: no sponsored posts, no affiliate links, no vendor writing about its own product under a byline. When a tool is recommended, the reason is in the article and the reason is the only reason.

How a post gets made

Those rules say what gets published; they say nothing about how a draft becomes a post. Here is that sequence in full.

1. The author picks the topic and writes the draft. The subject comes from something that actually happened in a production system, and the draft is written from those cases — the code as it was, the configuration as it was set, the numbers as they were recorded.
2. An AI editing pass prepares the text for publication. It anonymizes the material, removing client names, hostnames, internal paths, and anything else that would identify a system that did not agree to be written about. It fixes spelling, grammar, and the sentences that did not survive being written quickly. The pass edits prose. It does not produce findings, numbers, or claims, and it is not the source of any measurement on this site.
3. The author reviews the result before it ships. The edited text is read against the original, anything the pass changed wrongly is corrected, and the post takes its final shape there. Nothing publishes without that read.

The third step is the one that matters, because it is where the byline becomes accountable for every sentence under it, including the sentences an editing pass rewrote. A tool that removes a hostname can also remove a qualifier, and a draft that reads more smoothly is not the same thing as a draft that is still true.

Corrections are welcome for the same reason, and they are the fastest way to make a post better. Write to [email protected]: if a claim about the engine is wrong, a benchmark does not reproduce on your machine, or a version detail has changed since publication, say what you observed and the post gets fixed. A post corrected after publication carries an updatedDate, so a revised article is distinguishable from an untouched one.