DEV Community: Ilia Alshanetsky

php2shell: two ways PHP corrupts its own memory, and why turning that into a shell is still hard

Ilia Alshanetsky — Fri, 30 Oct 2026 13:39:33 +0000

A single unauthenticated request can run code as your web worker on PHP before 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. The bug is real, the patch is out, and reliable exploitation outside a lab is far harder than the headlines suggest. This is the full analysis, and an honest account of how long it took to prove (and why so long).

Lab-only research on a patched vulnerability. Knowledge sharing, not a how-to.

If you read nothing else, do these five things

Upgrade now to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. These fix CVE-2026-109618 and CVE-2026-109619. On an end-of-life branch, do not hand-apply an isolated source patch on top of the last EOL release: it closes these two CVEs but leaves you exposed to everything else fixed since the branch went out of support. Get a maintained build from your distro or a package maintainer (Ondřej Surý's deb.sury.org, Remi Collet's repo, Red Hat's module streams), which carry patched builds reaching back through 5.6, or upgrade. Check the package changelog for the CVE IDs before you trust any build. On Windows, take the -1 rebuild (8.5.12-1 and friends): that one bundles a separate Brotli 1.2.1 fix for CVE-2026-111497, an out-of-bounds write reachable through the cURL extension when automatic response decompression is on. Different bug, same download.
Set session.upload_progress.enabled=0, and turn off every extension and feature you don't use. The session flag is PHP's own published mitigation. The general habit, shrinking the attack surface, is the part that pays off on the next bug you haven't heard about yet.
If you run mod_php, move to php-fpm. The FPM process model removes an entire class of these chains and isolates workers from the web server. It raises the bar. It does not close the door: I got a shell on FPM too.
Exploiting this in the wild is hard. Not impossible, hard. Every chain is calibrated to one exact build, the heap grooming is fragile, and even with current LLMs doing the heavy lifting it took days of dead-ends to reach a reliable shell. Sansec and Wiz have both reported public "php2shell" PoCs that do not work against a default install.
This article explains the mechanism and the mitigations. It is not a copy-paste exploit kit, and the working lab harness targets the vulnerable 8.5.11 image only.

Credit where it is due

Discovery and analysis: Calif and Wiz. Their public write-ups, along with the PHP source patch, are what let me understand the issue well enough to reproduce it. If you want the discovery story and the wider impact catalogue, read theirs first.

The fix: the PHP team. "Avoid state corruption via bailout", authored by Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka, Nora Dossche, and Nicolas Grekas. They turned a messy memory-corruption class into a two-line conceptual fix: stop using zend_bailout on OOM, and reset the globals that startup touches.

Review: special thanks to Arnaud Le Blanc for reviewing an early draft and giving sharp, generous feedback that made this write-up more accurate.

Why this wasn't Log4Shell

The response was loud. NSA, the FBI, and the UK's NCSC all told anyone who could not patch immediately to take the affected system offline until it was mitigated; CISA said the same in its October 24 update, and days earlier had reported active exploitation and added both CVEs to its Known Exploited Vulnerabilities list. I would take the "active exploitation" label with a grain of salt. In waves like this, what gets reported as exploitation is often mass scanning and failed attempts. More than one vendor has quietly walked back a confident "actively exploited" claim once someone checked whether the traffic was a scan or a real shell, and this is not a bug that falls to a generic payload. The PHP team never called for shutting servers down. Their guidance was to patch, then apply the config mitigations.

Everyone reached for the Log4Shell comparison. So why wasn't the whole internet on fire? Why targeted hits instead of a mass, worming wave? The answer is in the offsets, and it is the reason this write-up exists.

The root cause: PHP panics by longjmp, and panic skips cleanup

When a PHP request exhausts memory_limit, the engine historically raised a fatal error and recovered with zend_bailout(), a longjmp back to a safe point. That unwind is the problem. A longjmp does not run the cleanup that a normal return would. If the allocation failed halfway through building a data structure, the half-built structure survives, and a global still points at it.

Both CVEs are that same mistake, caught in two different places.

CVE	What it is
CVE-2026-109618 · Bailout state corruption	An OOM during request startup, request parsing, or session handling leaves engine globals pointing at freed or half-initialized memory. The next request on the same worker inherits the mess.
CVE-2026-109619 · Pre-RINIT decode reuse	The upload-progress feature decodes a session before the request re-initializes its globals. With the unserializer left in a dirty state by a prior OOM, that early decode reuses a dangling structure.

The patch stops the OOM from longjmp-ing mid-operation. It defers the out-of-memory error and raises it at controlled chokepoints, an uncatchable UnwindExit while a userland frame is on the stack, and resets the globals that startup reads. 389 files changed, and a pile of new oom_rfc1867_*.phpt tests pin the exact spots where an allocation could fail mid-structure. On the supported branches an ordinary memory_limit hit is now a graceful fatal that still runs shutdown handlers; only a request that blows past a new hard ceiling, 200% of memory_limit, forces the process out with _exit(137). That rework did not reach the out-of-support branches: the fixes carried by distros and maintainers for 7.4, 8.0, and 8.1 take the blunt route and simply _exit(1) on the offending allocation, tearing the whole process down rather than attempting the unwind that caused the bug. Either way, the corrupting bailout is gone.

The primitive: one signed integer turns a session into an arbitrary write

Everything downstream rests on one function in the unserializer. var_tmp_var() hands out scratch slots from a block of destructor entries. It reads how many slots are used, then returns a pointer past them:

// ext/standard/var_unserializer.re  (simplified)
static zval *var_tmp_var_num(php_unserialize_data_t *var_hashx, zend_long num) {
    var_dtor_entries *var_hash = (*var_hashx)->last_dtor;
    ...
    zend_long used_slots;           // <-- SIGNED
    for (used_slots = var_hash->used_slots; ... )
        ZVAL_UNDEF(&var_hash->data[used_slots]);
    return &var_hash->data[used_slots];   // base + used_slots*16
}

used_slots is a signed zend_long. Make it negative and the returned pointer lands before the block, anywhere the attacker can reach. The session decoder then writes the parsed value through that pointer, one 8-byte value plus its type tag per session variable. Control where the block sits and what used_slots holds, and you have a controlled write with controlled data.

With that write, you build a lie: a chunk of memory that PHP believes is an array. The only field that matters is the array's destructor pointer. Aim it at the internal handler for system(), and the moment PHP tears the "array" down, it runs your command.

PHP's array teardown calls pDestructor(&bucket). Overwrite that one pointer with the address of zif_system, put the command where the bucket points, and freeing the array is a shell.

From one write to a shell: the four-request mod_php chain

A single write primitive is not a shell. You still need to know where to write, which means defeating ASLR, and you need something that turns a write into execution. The mod_php chain does both across four requests on one persistent Apache worker. It is pure HTTP. No files on the target, no debugger, no application code. The chain scripts live in off_chain/.

The payoff in B2 is a classic one: a fake PHP array whose destructor pointer is the internal handler for system(). When PHP tears the array down, it calls that "destructor" with attacker-controlled data, and the command runs as www-data.

$ cat out/proof
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Without the leak, every address is a guess, and a guess on a 64-bit ASLR heap is not an exploit. The forged zend_string read in B1 is what makes the rest deterministic.

Reading the layout from the wire: the Set-Cookie oracle

The leak needs no local access. It rides out on a header the server sends unprompted: when PHP starts a session it writes the session id verbatim into Set-Cookie: PHPSESSID=.... That id is a zend_string, and B1 controls which one.

A1's bailout freed the session-id buffer but left send_cookie=1 and the dangling PS(id) pointer in place. B1 reclaims that freed chunk with a crafted multipart field and overwrites it with a fake zend_string header: a benign refcount and type word, hash zero, and a len field widened to 2048. The character data is left pointing at the surrounding chunk. When the END cleanup emits the cookie, PHP copies len bytes starting from that pointer, so the PHPSESSID value becomes a 2 KB window of live engine memory rather than a 32-character id.

Everything after that is parsing on the attacker's side. parse_leak.php URL-decodes the cookie, walks it in 8-byte steps, and keeps the qwords that fall in the heap range. The pointer that recurs with its low 12 bits equal to 0x7a0 is zval_ptr_dtor, so libphp base is that value minus 0x7b47a0; bucketing the rest by 2 MB chunk recovers the main heap base. Two reads off one response header, and ASLR is gone from outside the process.

Six paths, two execution models, one scorecard

The same primitive reaches code execution through several routes. They are not equal. Some are pure HTTP, one still needs a debugger, and the FPM and mod_php models behave very differently under the same bug. Every path's exact container setup and commands are in RCE_PATHS.md.

Path	Model	What it is	Result
A	mod_php	Four-request chain, `display_errors=On`	shell
B	mod_php	Same chain, stock `php.ini-production`. Pure HTTP.	shell
B2	mod_php	Path B with a `popen` ROP stack instead of a direct call	shell
C	php-fpm	Session-decode reuse, app-visible leak, ASLR on	shell
C2	php-fpm	Path C fired through a `popen` ROP pivot, no forged `execute_data`	shell
E	mod_php	Multipart partial-bucket teardown (path1)	crash is HTTP-only; no native leak and the groom is blocked, so the write needs an external leak or a debugger

Why FPM is the harder target

mod_php runs PHP inside a long-lived Apache worker that shares the server's address space and survives across requests. That persistence is exactly what the four-request chain feeds on. php-fpm exits the worker the moment php_request_startup() fails, so the whole startup-failure class, including path1, simply cannot carry to a second request there. FPM is the more resilient model, and moving to it is good advice.

It is not a fix. The session-decode reuse (Path C) lives in exactly the pre-RINIT window FPM still has, and I landed a clean uid=33 on a stock FPM container. FPM falls two independent ways, in fact: the forged-frame route above, and a data-only variant (Path C2) that carries no fake execute_data at all. It overwrites the destructor with a jump_fcontext stack pivot into a short popen ROP chain, and fires it through the upload-progress hash update's own old-value destructor rather than the teardown. Same leak, same reuse, no forged frame. "Harder" is the honest word. "Safe" is not.

FPM kills the worker on a failed request startup, which is what blocks the mod_php chains. Path C slips through anyway: the upload-progress decode runs *before RINIT resets the worker, so request A's dangling d is still there for request B to reuse and overwrite with the same fake-HashTable frame. That pre-RINIT window is CVE-2026-109619.*

One more piece of honesty about the FPM result. The mod_php chains run out of memory at the stock 128 MB limit, driven by the request itself. Nothing on the target has to cooperate. The FPM chains here lean on a lab endpoint that hands back the pointer leak and, for determinism, sets memory_limit to 4 MB with ini_set() so a 1 MB session decode is enough to OOM. The 4 MB is a lab convenience, not a requirement. The arming OOM reaches the real 128 MB limit: a session record that declares a huge array count makes the deserializer pre-allocate the whole bucket table, 128 MB from under 5 MB of input, before it parses one element. The constraint the easy framing misses is where the OOM lands. It has to fire inside the session decode, so php_var_unserialize_destroy() is skipped and the context dangles. An ordinary base64 or image-resize OOM in application code aborts in the wrong place and arms nothing. So the FPM chain needs three things from the target, not one: the pointer leak, an OOM inside session deserialization, and attacker-influenced session content to carry that record. Stock PHP hands over none of them, and the leak is still the hardest.

A reader flagged that my FPM lab spoke FastCGI straight to php-fpm, a shortcut, not a requirement. So I reworked the lab to do it properly; the repo ships that path now: the same leak and write travel the full route over plain HTTP through a stock nginx with php-fpm unreachable from outside, and still land uid=33, roughly 6 fresh workers in 10, every miss a clean retry. The FPM result is remote through a normal reverse proxy, not an artifact of reaching php-fpm directly.

What I did leave on the table, deliberately, were routes that lean on an application weakness. If the target calls unserialize() on attacker input the primitive is one request away, but the PHP manual has warned for years that unserializing untrusted input gets you hacked. That is object injection, the application's bug, not PHP's. I wanted the vulnerability shown in core PHP on a stock install, through mechanisms every install ships, not against someone's vulnerable code.

The barrier the PoCs skip: every stage needs the same worker

The chains above share a requirement the lab quietly satisfies. All four requests have to hit the same PHP worker, because the corrupted state the exploit builds lives in that one worker's memory. With a single worker that is free, and a single worker is where I started. On a production server, with a pool of workers behind a load balancer, landing four requests in a row on one specific worker looks like the hardest part of the attack.

In the lab: one worker (apache2 -X, or a single FPM child). Every request lands on it, so the state carries for free. This is where most public PoCs quietly live, and it is not a real deployment.

In production: many workers, a load balancer in front, other clients in the mix. The four stages scatter across the pool, and the state built on one worker is invisible to the next.

The obvious fix, HTTP keep-alive to pin one connection to one worker, does not work here. The chain OOMs twice on purpose, and PHP closes the connection on a bailout: the response is HTTP/1.0 500 ... Connection: close even when the request asked to keep the socket alive, and the next request on it gets EOF. I confirmed it is the SAPI bailout handling and not an unread body: a plain fatal error and a script-level OOM both close the socket the same way. Keep-alive carries a chain of healthy 200s. It cannot carry a chain whose whole point is to run out of memory.

What does work, in the lab, is process pinning: hold every worker but one busy with slow, half-sent requests, so the single free worker serves all four stages. I got this to a clean shell on mod_php, 9 of 10 prefork children pinned, and on php-fpm, 3 of 4 workers pinned with truncated FastCGI records. Both landed uid=33.

Pinning in a lab is one thing. Against a live server it is the noisy option: other clients hit that free worker too, you rarely know how many workers there are, and a fleet of half-sent connections is the shape a WAF or a bored load balancer drops. But pinning turned out to be unnecessary. Behind a stock-default nginx the php-fpm workers share one listen socket and the kernel hands new connections out in a strict round robin, so on a quiet pool the attacker never lands four stages on one worker: they walk the whole pool. Prime every worker, leak every worker, prime again, fire every worker. That is 2N ordinary complete requests for a pool of N, no slow bodies, nothing held open. I ran this end to end through a stock nginx with php-fpm unreachable from outside, on pools of 2, 4, and 8, and it landed uid=33 on every pool. Live traffic perturbs the round robin and I have not measured the hit rate under load, so this is not a one-shot against a busy server. But it refutes the idea that a worker pool behind default buffering is itself a defense. The barrier that actually holds is the next one.

Every number is build-specific

This is why the public exploits don't work on your server. The chain is a list of offsets, and every one of them is pinned to a single compiled binary. Change the PHP build, the distro, or the CPU architecture, and they all move. A PoC calibrated on the author's machine is a crash on yours.

Offset	x86-64	aarch64 (52-bit VA)
mod_php `zval_ptr_dtor`	`libphp+0x7b47a0`	`libphp+0x761b80`
mod_php `zif_system`	`libphp+0x5996e0`	`libphp+0x5314f0`
user-pointer range	`0x700000000000` to `0x800000000000`	`0xf00000000000` to `0x1000000000000`
`BG(unserialize).data`	`bg+0x368`	`bg+0x348`
fpm leak: `BASE` (from leaked pie_ptr)	`pie_ptr - 0x7c9777`	`pie_ptr - 0x6e7810`

I ported the two leak-based paths from x86-64 to a stock ARM server and both worked: the mod_php chain gave a shell in 4 runs out of 5 across randomized ASLR bases, and the FPM chain in 3 out of 3. That port did not need new exploitation ideas. PHP's internal struct layout and allocator bin sizes are identical on 64-bit ARM, so the small-bin spray and the heap grooming carried over untouched. What changed was a short list of symbol offsets and one pointer-range constant. The leak absorbs the rest, because it reads the current build's addresses at run time instead of hardcoding them. The full re-derivation method is in PORTING.md.

The fixed-address FPM variant, and why I left it out

There is a sixth route I built early and then abandoned: an FPM type-confusion that hardcodes every address instead of leaking one. The worker runs under setarch -R with ASLR off, so the PIE base and the reclaimed unserialize buffer d sit at fixed addresses across runs. Two files carry the whole exploit: a session blob sess_T whose values are d-relative pointers into a fake var_dtor_entries table, and a fill payload fillU.bin that sprays that table into the freed block so the signed-used_slots write lands on a crafted HashTable. No leak, no second request to parse one. On the exact build it was tuned against, it drops a shell on the first try.

It is also the only path I could not reproduce on a clean official image. Nothing about the bug changed; the heap did. On the freshly pulled php:8.5.11-fpm the reclaimed d came back 0x495000 away from the address baked into sess_T, so every d-relative pointer in the payload aimed into unmapped memory. Re-deriving d was not enough. The fill groom itself mis-landed: the spray reclaimed the d allocation as its own zend_string, which put the string's length word (0x1fea, 8170) exactly where last_dtor lives at d+0x10, and var_tmp_var then dereferenced 8170 as an entry count and faulted. The fixed address was not stale, it was occupied by the wrong object.

Fixing that is pure allocator choreography with no new capability at the end of it: re-derive d under the probe, rebase every pointer in sess_T and fillU.bin onto the new base, then re-tune the fill part size and count until the reclaim lands on the freed var_dtor_entries block instead of on d, and repeat for the next image release. Path C reaches the same FPM worker with a live leak that reads the current base at run time, so it absorbs all of this for free and ported to ARM with constant edits only (3 shells in 3 runs). The fixed-address variant demonstrates nothing Path C doesn't and breaks on every rebuild, so I left it out of the paths I stand behind. I am keeping the artifacts only as a worked example of how a build-specific heap groom decays, which is the real lesson: an offset is a fact about one binary, not about the bug.

Mitigations, mapped to what they actually buy you

Action	What it does
Upgrade to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35	Removes both CVEs at the source: no more bailout corruption, no more dirty-state reuse. This is the fix; everything below is defense in depth.
Windows: the `-1` rebuild	Adds Brotli 1.2.1 for CVE-2026-111497, a separate cURL-reachable OOB write. Same PHP runtime, updated dependency.
`session.upload_progress.enabled=0`	Removes the pre-RINIT session consumer the FPM and mod_php session chains rely on. PHP's own stopgap. Does not touch path1.
mod_php → php-fpm	Removes the startup-failure class and isolates workers. Not a cure.
Disable unused extensions and settings	The habit that pays on the next unknown bug. Every decoder you don't load is a decoder that can't be confused, and the same goes for INI switches you do not need: turn off `cgi.fix_pathinfo`, `expose_php`, and any feature your application never uses.
Confine the worker (AppArmor / SELinux / seccomp)	A profile that stops the PHP worker from spawning a shell blocks the `system()` payload, and it bites where `disable_functions` cannot: this bug calls the internal handler by address, so `disable_functions` is bypassed (I confirmed it fires with `system` disabled). Docker makes a tailored profile cheap to apply, though the default Docker profile still allows shell exec. Defense in depth, not a cure: a worker running attacker code can still `readfile()` your `.env`, keys, and source through PHP and hand them back in the response, no shell needed. Only the upgrade removes the bug.

How this was done, honestly

A closing note on the effort, because the "hard even with LLMs" line up top deserves receipts. This is the story of actually building the thing, dead-ends and all.

I did not find this bug, and my first swing at it missed. The night before the patch I heard about it and spent a few late hours trying to reason it out. I got as far as the two parts that matter, a longjmp on OOM and memory_limit, and then told myself the wrong story. I was certain it had to route through serialization and the internal flags around it, so that is where I dug, and that is where I stayed stuck. Some of the information floating around online pointed the same wrong way, and I took it at face value. I'll blame the late hour rather than look too hard at my own incompetence 😆.

Then the patch landed, the shape of the thing got clearer, and the OCD kicked in. I wanted the full what, why, and how, so I set out to reproduce it end to end. The process was deliberate. I wrote up my own analysis first, a long guide and prompt laying out my theory of where the bug lived, how to reproduce it, and the path from there to a shell, then handed the exploration to DeepSeek V4.1 Flash 1017, under one firm rule: when it got stuck or unsure, it stopped and asked me how to proceed instead of guessing. At the dead-ends I gave direction and, a few times, code. We iterated over several days. Whole approaches looked right and went nowhere. The model was a regular, non-abliterated release. No jailbreak, no uncensored fork. A mainstream aligned model, pointed at a patched vulnerability, with a human in the loop the whole way.

The final validation and this write-up were mine, with Claude Opus. That last mile was the real test of the "hard even with LLMs" claim in the TLDR. Getting a shell on a known-vulnerable container is one thing. Getting the same chain to fire reliably, re-deriving every offset by hand for a new build, porting it from x86-64 to an ARM machine, that is where the days went. The AI accelerated the work. It did not trivialize it.

One more thing on the effort, because it matters. I am a PHP core developer. I have been release manager for over 20 PHP releases, I know my way around the engine internals, and I have spent years on the security side. I am not a neophyte poking at a black box, and it still took days of guided work, wrong turns, and hand re-derivation to reach a reliable shell. So when someone tells you they typed "find me an exploit" into a chatbot and out came a working php2shell chain, they are, quite frankly, full of shit. The prompt is not the hard part. The offsets are.

What this bug is, and what it isn't

php2shell is a genuine unauthenticated RCE, and if you run an unpatched PHP you should treat it as one and upgrade today. It is also a reminder that the distance between "a bug exists" and "a stranger owns your box" is measured in offsets, heap state, and days of patient grooming. The patch deletes the bug the whole path is built on, so there is no path left to walk. That is the only outcome that matters. The researchers who found it did the hard part; the PHP team shipped the fix fast; and the footnote is that even with a capable model doing the grinding, turning this into a reliable shell was work. That gap is not a reason to relax. It is why the upgrade is the whole answer.

Corrections welcome

This gets more accurate when people who know more poke holes in it. If I missed a path, botched an offset, or told the story wrong, tell me: email ilia@ilia.ws, DM me on X at @iliaa, or find me in the usual Discords :P.

Reproduction harness, per-path notes, and the full offset tables live in the companion repository, github.com/iliaal/php2shell, which targets the vulnerable 8.5.11 images only. Patched releases are the control in every test.

Seventeen Seconds to Parse One Name: A Security Scan Across Eleven PHP Projects

Ilia Alshanetsky — Tue, 27 Oct 2026 13:32:13 +0000

This is a 16 KB name:

$row = 'Smith, ' . str_repeat('V ', 8188);
(new \Iliaal\NameParser\Parser())->parse($row);

On nameparser 1.5.0, the last version before the fix, that call takes 17.4 seconds of CPU on my i9-13950HX. On 1.7.0 it takes 0.064 seconds. Each V is a candidate roman-numeral suffix, and the old suffix scan walked back over every earlier token for each one, so the cost grew with the square of the input. Nothing about it is exotic. It is a plausible shape for a junk row in a CSV import, and it pins a PHP worker for as long as the row keeps coming.

I didn't find it. A security scan did, and the same scan ran across all ten of my PHP extensions as well. In the first three weeks of October each project got a full pass: one coordinating session, a set of subagents reading code and writing proof-of-concept exploits, and a separate verifier that re-ran every finding before it counted, on its own ASan and release builds for the C code. Everything below ships in releases from the last few weeks.

Two other things landed in the same window. PHP's October security releases changed what memory_limit does, which forced code changes in three extensions and a same-day round of re-releases in five more. And DuckDB 2.0 went GA; pdo_duckdb bundles it as of today.

What the scans found, and what is fixed

Every project in the table has a release that carries its fixes. The counts are findings confirmed by the verifier, fixed, and released; severities are the verifier's, not the scanner's first guess.

Project	Fixed in	Confirmed and fixed
phpser	0.7.1	19: 1 high, 5 medium, 13 low
mdparser	0.8.0	12: 1 high, 5 medium, 5 low, 1 informational
fastchart	1.8.0	15 reproduced, highest medium, including vendored plutovg and plutosvg; two UBSan sites in vendored code only partly addressed
php_clickhouse	0.13.0	1 high, 1 medium, plus low-severity binding fixes and 7 server-triggered crashes in clickhouse-cpp
pdo_duckdb	0.8.0	6: 1 high, 1 medium, 1 low-medium, 2 low, 1 informational
fastjson	0.10.0	4: 1 medium, 3 low, plus 1 documentation correction
php_excel	2.9.0	5: 3 low, 2 informational
statgrab	2.3.0	4: 2 medium, 2 low, plus a build bug
fast_uuid	0.8.1	5: 4 low, 1 by-design behaviour changed anyway
phonetic	0.4.4	3: 1 medium, 2 low
nameparser	1.6.0	5: 1 medium, 1 low, 3 informational

A few findings in upstream libraries are reported privately to their maintainers and aren't described here until fixes ship.

The coordinating model was Mythos 5.1, but most of the work ran on other models: on fastjson, 695 of the 702 assistant messages came from Opus 5.5 subagents doing the reading, fuzzing, and PoC writing. The phpser scan doubled as an A/B/C test of my own tooling against a bare prompt, which I wrote up on X at the time. So the table measures the process more than any one model.

fast_uuid and phonetic came back with zero memory-safety bugs, and php_excel's wrapper with nothing above low severity.

Bugs that needed no attacker

The worst php_clickhouse finding in practice wasn't the high-severity one. It was B-4, which corrupted data on ordinary queries. Decimal and DateTime64 decoding cached each column's scale in a memo keyed on the raw address of the column's type object. clickhouse-cpp allocates a fresh type object per column per block and frees the block after each callback, so the next block's first column could land at the same address and inherit the previous column's scale. Select a scale-2 column next to a scale-6 one with max_block_size=100, and a stored 12.34 came back as 0.001234, with no error. With default settings the verifier still saw 1 wrong cell in 70,000 rows.

The test suite never caught it because ASan builds hide it: the sanitizer's quarantine stops freed memory from being reused, so the address never repeats. It took a release build and a real server. 0.13.0 keys the memo correctly.

0.13.0 also fixes a behaviour you should check for before upgrading. A whole-number insert into a Decimal column, 7 into Decimal(9,2), now stores 7.00 as the server does; 0.12 stored 0.07. Code that compensated by passing pre-scaled integers (700 meaning 7.00) will now store 700.00 without complaint.

fast_uuid's main finding has the same character. uuid1() and uuid6() with a fixed node and clock sequence kept no last-tick state, so uuid1(1, 7) called 500,000 times produced 61,723 duplicates. The default arguments were fine. 0.8.1 fixes it.

Bugs a server, a file, or a document could trigger

php_clickhouse's high-severity finding was a heap overflow write. With compression enabled, a malicious or compromised server could send a compressed frame whose declared size was smaller than the 9-byte frame header, and the client wrote past its buffer with bytes the server chose. clickhouse-cpp had already fixed it on master in PR #566, but no clickhouse-cpp release contains the fix yet, and php_clickhouse's prebuilt binaries ship the library. 0.13.0 carries the patch. The same release rejects seven more server-triggered crash shapes, from FixedString(0) columns to Array offsets that run backwards, and stops a packet of a few dozen bytes from committing gigabytes of memory outside memory_limit. I sent the fixes upstream as 15 pull requests; three have merged so far and twelve are open.

fastchart's two medium findings were both resource bombs. A 44 KB SVG passed to svgTo*() reached 2,121,264 KiB of resident memory through data URIs and <use> references that slipped past the input gate, all of it outside memory_limit; a 30,000-deep <use> chain crashed the process. A 1 MB CgBI PNG with decoy dimensions decoded into a 16000 by 16000 buffer. 1.8.0 runs the gate on the parsed tree, bounds <use> depth and expansion, and caps decoded images at 4,096 pixels a side. Some heavy but legitimate SVG that used to render slowly now throws a ValueError instead, so test your largest inputs.

mdparser's high-severity finding was quadratic parsing: blank lines inside deeply nested lists took 1.7 seconds at 200 KB and 55 seconds at 1 MB. Seven of mdparser's thirteen findings had their root cause in md4c rather than in my code, and the fixes went upstream; md4c merged five of my pull requests for them on October 13. One remaining low-severity signed overflow is still waiting in md4c#374. 0.8.0 also changes generated heading IDs to start with user-content-, which closes a DOM-clobbering finding and breaks existing links to heading fragments when headingAnchors is on.

The other high and medium findings

pdo_duckdb's high finding was a use-after-free: an appender left open inside a reference cycle could outlive its PDO handle when gc_collect_cycles() or request shutdown freed the handle first. Two of the medium-range findings were the same shape. A memory_limit bailout at the wrong moment during column setup left uninitialised type pointers that were destroyed later; the PoC got the sanitizer to report a destructor running on 0x4141414141414141. 0.8.0 fixes all six.

phpser's high finding was that a nested SPL unserialize() ignored allowed_classes. Its legacy handler path ran outside the decoder's context, so a class allowlist set on the outer call never reached the inner one. 0.7.1 fixes it along with eighteen others, most of them bounds on work an untrusted payload could demand.

nameparser's quadratic case, from the top of this post, is fixed in 1.6.0. Its release notes say plainly that earlier notes describing hostile-input parsing as linear "did not hold for these shapes". phonetic's medium finding was a 14-byte input, bmpm("de akeaxhaeasz"), that caused an uncatchable fatal error. 0.4.4 turns budget overruns into a catchable ValueError and caps BMPM output at 256 times the input size, after a 1,560-byte input had produced 3.9 MB.

memory_limit stopped stopping things

PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 shipped on October 21 with the fix for CVE-2026-109618, rated critical. Part of that fix changes what happens when an allocation crosses memory_limit. The engine used to bail out on the spot with a longjmp. Now it records the error, lets the allocation succeed, and raises the fatal at the next safe point in the VM.

For PHP code that's invisible. For an extension it isn't. A C loop that decodes a payload or builds rows never reaches a VM safe point, so it keeps allocating past memory_limit until it hits a hard limit, by default twice memory_limit below 1 GiB. At the hard limit the engine calls _exit(): no shutdown functions, no destructors, no session write, and php-fpm loses the worker instead of failing one request.

So every loop whose length comes from input has to notice the pending error and stop on its own. This is how phpser does it:

/* PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 queue a memory_limit error instead of
 * bailing out; the allocation still succeeds until a hard limit (2x the soft
 * limit below 1G) that _exit()s the process. Loops that keep allocating must
 * stop on their own once the error is pending. */
#ifdef ZEND_HAS_OOM
# define PHPSER_HAS_OOM() ZEND_HAS_OOM()
#else
# define PHPSER_HAS_OOM() 0
#endif

A loop check cannot help when a single allocation is sized from a count the payload declares. Those go through the new fallible allocators instead (zend_hash_real_finit(..., true), safe_femalloc, fecalloc), which queue the error and return NULL rather than running into the hard limit. phpser 0.10.0 uses both. mdparser 0.8.1 and pdo_duckdb 0.9.0 do the same for their input-sized loops and presizes.

The re-release day

There is a catch. The October headers route smart_str growth through a new engine function, smart_str_ferealloc(), from inline header code. An extension compiled against 8.4.27 headers imports that symbol even if it never mentions it, and 8.4.26 doesn't export it. My release workflows built prebuilt binaries against the newest patch of each PHP minor, which had always been the safe choice.

On October 26 that meant mdparser 0.8.1, phpser 0.10.0, fastjson 0.10.1, php_clickhouse 0.13.1, and phonetic 0.4.5 all shipped Linux and macOS binaries that died with undefined symbol: smart_str_ferealloc on every PHP 8.4 before 8.4.27 and every 8.5 before 8.5.12. Source builds were fine, because they compile against the PHP they load into. All five were re-released the same day as mdparser 0.8.2, phpser 0.10.1, fastjson 0.10.2, php_clickhouse 0.13.2, and phonetic 0.4.6, and fastchart 1.8.1 picked up the same change before it could break. Their prebuilts now compile against the oldest patch of each minor (8.4.1, since 8.4.0 was never released, and 8.5.0), and each binary has to load on both the oldest and the newest patch before anything uploads.

That fix has a cost, and the phpser changelog states it: a binary built against 8.4.1 headers doesn't have the memory_limit stop. To get it, you build from source on a patched PHP.

Refusing vulnerable PHP releases

The longer-term answer is the opposite trade. pdo_duckdb 0.9.0 makes it today: its prebuilt binaries are built against the patched headers and require PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or newer. Load one on 8.4.26 and the process stops at the first call:

php: symbol lookup error: /ext/pdo_duckdb.so: undefined symbol: smart_str_ferealloc

That message is honest but unfriendly, and it arrives at runtime rather than at startup. The next releases of pdo_duckdb, phpser, and mdparser fix that with a startup check. On PHP 8.3 and newer, the module compares the running patch with the one it was compiled against and refuses to start on an older one, naming both versions. This is mdparser's:

if (php_version_id() < PHP_VERSION_ID) {
    zend_error(E_CORE_WARNING,
        "mdparser was built for PHP %s and cannot run on PHP %s; "
        "install a build for this PHP version or build from source",
        PHP_VERSION, php_version());
    return FAILURE;
}

With that check in place, pdo_duckdb keeps the binaries it already builds against the patched headers, and phpser and mdparser can move theirs back to the patched headers and regain the memory_limit stop. A server still on 8.4.26 gets a clear startup warning instead of a crash on the first request, and with a critical CVE fixed in 8.4.27 it should move anyway.

pdo_duckdb 0.9.0: DuckDB 2.0

DuckDB 2.0.0 went GA on October 21, and pdo_duckdb 0.9.0, out today, bundles it in every prebuilt binary. 0.8.0 had already built against the 2.0 previews. Source builds still work against DuckDB 1.5.3 and newer; configure detects 2.0 from duckdb_v2.h, because the 2.0 headers still report C API version 1.5.6, and it refuses to build when 2.0 headers meet an older libduckdb.

The upgrade is not transparent, and the README has a full section on it. The one most likely to bite is the file format. DuckDB 2.0 writes new files at storage version 69, and DuckDB 1.5 reads only 64 to 68. If a 1.5 process has to read the file too, ask for the older format when you open it:

$db = new PDO('duckdb:/data/shared.duckdb;storage_compatibility_version=v1.5.6');

On the 0.9.0 binary, a file opened that way reports v1.5.0+ in duckdb_databases(), and a default one reports v2.0.0+. Existing 1.5 files keep their format after 2.0 writes to them. The rest is DuckDB's own behaviour: a failed statement now invalidates the whole transaction, integer division by zero throws, single-arrow lambdas are rejected, and the new PEG parser is the default. That last one has a sharp edge for parameter binding: $1_0 means parameter 10 under PEG and parameter 1 under the legacy parser. Each change has a setting that restores 1.5 behaviour.

0.9.0 also adds PDO::DUCKDB_ATTR_NATIVE_STRUCTURES, an opt-in that fetches LIST, ARRAY, STRUCT, TUPLE, MAP, UNION, JSON, and VARIANT values as lossless PHP structures instead of canonical strings, with exact numerics, binary keys, and SQL NULL kept distinct from VARIANT null. VARIANT works top-level and nested, and the appender accepts PHP arrays and objects for it.

One fix in 0.9.0 matters even if you never touch 2.0: two PDO connections to the same database file could lose writes and see stale reads. Equivalent paths now share one DuckDB instance while transactions stay connection-local.

Performance, with the hardware attached

Most of the speed work came before the scans. Apart from the nameparser row, which I re-ran for this post, these are the numbers from each project's changelog with the conditions it states.

Project	Change	Measured on
nameparser 1.6.0	16 KB hostile row: 17.4 s to 0.064 s	i9-13950HX, PHP 8.4.27 (my rerun of 1.5.0 vs 1.7.0)
phpser 0.6.0	`range(0, 9999)` encodes to 7 bytes; encode 57% faster, decode 66% faster	aarch64
phpser 0.7.0	Signed decode 53 to 85% faster; 1,000-row rowset decodes in 429 KB instead of 645 KB	aarch64
fastjson 0.9.0	`fastjson_validate()` costs 0.47 to 0.90x a full parse, down from 1.1 to 1.9x	Neoverse-N1
fastjson 0.9.0 to 0.10.0	Key-heavy decode peak memory about 15% lower; file decode peak 9 to 33% lower	Neoverse-N1
fast_uuid 0.8.0	`uuid_v4()` 76 to 42 ns; `uuid_v4_bin_batch(100)` 61 to 27 ns per UUID; `uuid_v7_bin_batch()` 25.9 to 16.6 ns	Neoverse-N1
mdparser 0.6.2	`toAst()` 5 to 9% faster; retained AST memory 47% lower on softbreak-dense input; code-heavy `toXml()` output 49% smaller in memory	aarch64, PHP 8.4.25
php_clickhouse 0.12.0	Temporal, string, and IP inserts about 19% faster; IPv4 selects about 12%	200,000-row probes

The phpser integer-run encoding is the one I'd point at. A run with a constant step is stored as a start, a step, and a count, so range(0, 9999) encodes to 7 bytes and range(0, 999999) to 8. Native serialize() needs 137,790 bytes for the first one.

fast_uuid's speedup comes from refilling its random buffer with a userspace AES-256-CTR generator with fast key erasure, instead of a getrandom() call per 8 KiB, on CPUs with AES instructions. It has one caveat, and the changelog states it: clones of one VM snapshot can repeat up to 64 KiB of output per thread.

Breaking changes worth reading before you upgrade

Most of these releases are drop-in. These are not:

php_clickhouse 0.13.0: whole-number Decimal inserts scale like the server's (above).
mdparser 0.8.0: heading IDs carry a user-content- prefix.
phpser 0.10.0: Closures and other unserializable objects throw instead of quietly encoding NULL. Check what you put in $_SESSION before upgrading. New wire tags since 0.7.0 mean readers must upgrade before writers.
php_excel 2.9.0 and 2.9.1: dates use PHP's timezone rather than the OS one, and text is UTF-8 regardless of the process locale. Apps that relied on the locale to pass non-UTF-8 bytes through will see different output. 2.7.0 also rejects a font from a different ExcelBook in addText().
fastchart 1.8.0: heavy SVG that used to render slowly may now throw ValueError.
phonetic 0.4.4: oversized BMPM and Daitch-Mokotoff work throws a catchable ValueError rather than ending the request.
statgrab 2.2.2: Statgrab::ERROR_UNSUPPORTED is 44, matching libstatgrab; it was 41.

On the feature side, phpser 0.8.0 and 0.9.0 added signed sessions (phpser.session_key, HMAC-SHA256), an APCu serializer (apc.serializer=phpser), keyed payloads, and an exported C API. nameparser 1.4.0 understands joint salutations, so Mr. and Mrs. Brad Smith keeps Brad as the first name, with new isJoint(), getSalutations(), and getPartner(), and 1.4.1 raised first-and-last accuracy on 30,000 NPPES provider rows from 95.94% to 97.18%. statgrab 2.3.1 fixes a heap overflow in the bundled libstatgrab's Linux command-line handling that the scan didn't cover.

What a scan is worth

None of these projects were neglected before October. Each had a test suite and documentation that said where its limits were. The scans still found an allowlist that didn't reach a nested call, a Decimal that came back ten thousand times too small, and a 16 KB name that took 17 seconds. Two of the most consequential findings sat in code I had already called linear or already tested under ASan, and for the Decimal bug the ASan testing is exactly what hid it.

The fixes are released and listed above. Upgrade pdo_duckdb if you are moving to DuckDB 2.0, php_clickhouse if you talk to a server you don't control, and PHP itself to 8.4.27 or 8.5.12 whatever else you do.

CodeSage: Code Intelligence for AI Agents, and Why I Rebuilt Its Models

Ilia Alshanetsky — Fri, 02 Oct 2026 11:23:47 +0000

Until this week, CodeSage ran its two models exactly as they ship on Hugging Face: Jina's code embedder and the ms-marco MiniLM reranker. A full index of php-src took 1,782 seconds, just under half an hour, and I got tired of waiting.

CodeSage 0.38 does the same full index in 373 seconds. Nothing was retrained. The weights are the same weights; what changed is the inference graph around them, a few things in the chunker, and one SQLite query that had been quietly eating most of the run. The two rebuilt models are now public on Hugging Face, along with the scripts that produce them byte-for-byte.

What CodeSage gives an agent

CodeSage is a code intelligence engine for AI coding agents: a structural graph (symbols, references, dependencies) plus semantic search (embedding retrieval with cross-encoder reranking), in one Rust binary that works as a CLI or an MCP server. An agent asks it questions grep can't answer, like "what depends on this class" or "where does session handling happen", and gets file-and-line answers from an index instead of guesses from a context window.

Parsing is tree-sitter, covering PHP, Python, C, C++, Java, Rust, JavaScript, TypeScript and Go. Each project gets one SQLite database at .codesage/index.db, with sqlite-vec for KNN and FTS5 for literal matches. The MCP side is a stdio shim that starts or reuses a per-user daemon over a Unix socket, so concurrent agent sessions share one project cache, one model pool and one CUDA context. There is no HTTP listener.

The MCP server exposes 22 tools. The ones agents lean on most:

find_symbol, find_references, trace_call_path: where something is defined, who calls it, and the shortest call chain between two symbols.
impact_analysis, assess_risk: what a change to this file can break, scored from the graph plus git history.
search: natural-language retrieval over ~50-line chunks, reranked.
from_trace: maps a pasted stack trace or ASan report (Python, PHP with Xdebug, Rust, Java, Go, Node, gdb) onto indexed symbols.
edit_check: diffs a proposed declaration against HEAD before the agent writes the file.

The graph is only as useful as its recall. In August, impact_analysis reported that AxiosError in axios had 0 dependents. It has 23. File-path imports like ./core/AxiosError.js never resolved; only Rust-style :: paths did. Fixing that, and counting Foo.staticMethod() and x instanceof Foo as usage, took mean dependent recall on axios from 0.37 to 0.66 at precision 0.85. An agent told "0 dependents" by a tool it trusts goes ahead and changes the class.

The index has to keep up with the code

An index that lags the code feeds the agent stale answers with full confidence, so CodeSage re-indexes from git hooks on every commit, checkout and merge. That puts the indexer's fixed cost on the hot path dozens of times a day, which is why a lot of the work across 46 releases since April has gone into cost rather than features.

The per-commit path got there first. In 0.23.0, a no-change incremental run stopped loading the ONNX model and mapping a CUDA context before checking whether any file had changed:

No-change incremental `codesage index`	Time	Peak memory
0.22.0	2.7-4.5 s	1.16 GB
0.23.0	0.08 s	150 MB

The file watcher re-embeds only chunks whose text changed: an 8-save burst marks 90 chunks dirty and embeds 1.

That leaves the full index, which nobody runs on every commit but everybody runs eventually: first onboarding, a model change, a chunker change. 0.38 itself forces one, because the embedder now reads up to 1,024 tokens per chunk instead of 512. When the full run takes half an hour on a large repo, people postpone it, and a postponed re-index is a stale index.

Same weights, rebuilt graphs

The embedder was slow because of how it was exported, not because of what it computes. The upstream Jina v2 ONNX file is a decomposed opset-11 export. Its attention uses ALiBi plus a QK LayerNorm, a combination ONNX Runtime's transformer optimizer doesn't recognize, so nothing fuses. Every layer materializes the full [batch, 12, seq, seq] score tensor several times over, and because the graph outputs per-token hidden states, every batch copies a [batch, seq, 768] tensor from the GPU back to the host just so the caller can average it.

IA0x00/jina-embeddings-v2-base-code-codesage carries two graphs:

onnx/model.onnx (fp32, every execution provider): masked mean pooling and L2 normalization folded into the graph, so the output is the 768-dimension sentence embedding and nothing else crosses back to the host.
onnx/model_cuda_fp16.onnx (CUDA only): the same pooling, plus attention fused by hand into com.microsoft MultiHeadAttention, with ALiBi and the key-padding mask passed as attention_bias. Weights are fp16; the output stays fp32.

One fp16 detail: the attention mask filled padded positions with -FLT_MAX, which overflows fp16. It's -10000.0 now, which is still negative enough to zero those positions after softmax.

Measured on an RTX 4080 Laptop GPU with ONNX Runtime 1.24.4, 2,048 real chunks per corpus of up to 512 tokens each, compared against upstream fp32 with pooling done on the host:

Corpus	Upstream fp32	Pooled fp32	Fused fp16	Min cosine (fp16)	Top-10 neighbour overlap
php-src (C)	59.7 chunks/s	89	249-257	0.99999	0.994
Laravel app (PHP)	67.2	113	301-317	0.999996	0.996
React app (TS/JS)	69.8	109	296-317	0.999995	0.997

A minimum cosine of 0.99999 across 2,048 chunks means the vectors are, for retrieval purposes, the same vectors. Those throughput figures are at the 512-token cap; CodeSage now runs Jina at 1,024, because real C in php-src runs a median of 611 tokens per 1,500-byte chunk and the old cap truncated more than half of them. So the production per-chunk rate is lower than this table, and the chunks carry more of the code.

The reranker needed far less. IA0x00/ms-marco-MiniLM-L6-v2-codesage is a standard BERT, so ONNX Runtime's stock optimizer fuses it (embedding LayerNorm, six Attention nodes, skip LayerNorm, bias GELU) and the work was mostly converting to fp16. Scoring 50 (query, chunk) candidates went from a median 108.0 ms per query to 20.6 ms, with the same top result on 40 of 40 test queries, top-10 overlap of 0.9975, and a maximum logit change of 0.024.

Both repositories are Apache-2.0, the upstream license, and the weights are unchanged apart from precision. CodeSage pins each one by Hugging Face commit and by the sha256 of every graph and tokenizer it loads, and scripts/derive-jina-onnx.py and scripts/derive-reranker-onnx.py in the CodeSage repo download the pinned upstream files, verify them, and write the published files byte-for-byte. You don't have to trust my upload; you can rebuild it. Your config.toml keeps the upstream model names, and the pin table maps them to the derived repos, so there is nothing to change on upgrade.

The biggest single win wasn't a model

Most of the half hour was SQLite. When a file changes, its old chunks are deleted first, and file_path lived in an auxiliary column of the sqlite-vec table and an UNINDEXED column of the FTS5 table. Neither can be searched by index, so DELETE ... WHERE file_path = ? scanned both tables for every file: about one second per file at php-src's 54,000 rows, roughly 20 of the 28 minutes a full index took when I measured it.

The fix is a small sidecar table, <chunk_table>_paths(id, file_path), kept in step on every insert and delete and rebuilt if it goes missing or diverges. Deletes now resolve the path to rowids and remove by rowid: 3.2 ms per file.

Two chunker changes ship in the same release. Chunks that are mostly digits and commas (lookup tables, timezone and Unicode data) are no longer embedded, since no natural-language query is looking for them, and batches are length-sorted and byte-bounded so a batch of short chunks isn't padded out to the length of its longest member.

Before and after, all of it together:

`codesage index --full`	Before	0.38
php-src	1,782 s	373 s
private mobile backend	469 s	80 s
private frontend app	295 s	60 s

That is the combined effect of the fused fp16 graph, the 1,024-token cap, the dropped data chunks, the batching, and the delete fix. I don't have a clean per-change split beyond the delete scan's own estimate, so I'm not going to invent one. Retrieval held: recall@10 is unchanged on three private eval corpora and rose from 0.765 to 0.790 on a php-src session corpus.

Scores that say what they measured

Fast answers are worthless if the agent can't tell a measurement from a default, so several releases since August went into making CodeSage say what it didn't check. impact_analysis reports a lower bound, because dynamic calls and unresolved imports can hide real dependents. assess_risk returns unscored for a file with no indexed git history instead of a low number. find_references marks a count as a floor when the symbol name is ambiguous. An empty search result carries indexed-file counts per language, so "not found" and "never indexed" stop looking identical.

The same rule applies to my own benchmarks. In August I withdrew a published retrieval number (recall@10 0.932, NDCG@10 0.788 over 602 queries) after finding the harness had indexed whole repos instead of each benchmark's root and scored crashed queries as 0.000. The replacement table in the README runs 663 queries across 33 repos in 9 languages, reports per-language NDCG@10 from 0.7455 (C) to 0.9434 (JavaScript), and says it was measured on a modified 0.27.0 build. It hasn't been re-run on 0.38 yet.

Where it falls short

These are the limits I know about, all of them in the README:

Nine languages. On the public benchmark, 47% of queries are in languages CodeSage doesn't parse (Ruby, Kotlin, Swift, Scala) and get no recall at all.
Agents don't reach for it on their own. With CodeSage and Grep both available in Claude Code, agents picked CodeSage on code-identifier queries 1.1% of the time over 30 days of sessions, and 0 of 10 on a controlled harness (measured in April, not re-measured since). That is why the codesage-tools Claude Code plugin serves a codesage brief inline before an Edit or Write in an onboarded project instead of waiting to be asked. It stays silent when there is nothing worth saying.
Every speed number in this post is CUDA. CPU and Apple's CoreML get the pooled fp32 graph but not the fused fp16 one, and I haven't measured the CPU side.
No prebuilt binaries and no documented Windows support. You build it with cargo.
Read-only. It doesn't edit code and doesn't query across repositories.

Try it

cargo build --release -p codesage --features cuda   # drop --features cuda for CPU / CoreML
cd /path/to/your/project
codesage init
codesage index
codesage install-hooks
claude mcp add --scope user codesage -- codesage mcp

Codex users run codesage install codex --global instead of the last line. If you're on Claude Code, whetstone is the other half: CodeSage tells the agent what the code is, whetstone covers how to investigate, review and ship. The first index downloads the models: about 370 MB on CUDA, about 736 MB for the fp32 graphs on CPU or CoreML.

Nothing about CodeSage 0.38 required a better model. It required looking at what the existing one did between input and output, and at what the database did on every file delete. Most of that half hour was overhead around the model, not the model itself.

github.com/iliaal/codesage

The Cost of Failing Closed: What Shipped Across Nine PHP Extensions

Ilia Alshanetsky — Mon, 27 Jul 2026 19:19:25 +0000

Making ExcelBook::save() atomic is easy to describe. Write the workbook to a temporary file, then rename it into place. A save that dies halfway leaves the original file untouched.

The obvious way to build that staged file is to ask LibXL for the finished archive as one buffer and write the buffer out. It works. It also costs 67.7 MB of peak RSS on a 3.3 MB workbook, and the PHP-side copy counts against memory_limit. The streaming writer php_excel used before the staging work costs 0.7 MB for the same file. That is roughly twenty times the workbook size in RAM, spent by a change whose whole purpose was safety.

That one arrived and was fixed inside the same release window, so no published version carries it. It is still a fair summary of the last two weeks. Nine of my PHP extensions released today. Between them they add one new method, one set of interfaces, and a few error constants. Everything else is a bug fixed, a value rejected, a limit enforced, or a cost paid back down.

The previous roundup ended on the claim that most of the work in these extensions is the unglamorous kind. This cycle is what comes after that claim, and it has a bill attached. Checking something on every row costs something on every row. Staging a write costs memory. Validating a wrapper at construction costs construction time. Most of the performance work below is repair rather than new optimization: finding where the safety checks got expensive, and making them cheap again.

php_excel 2.6.0: every save stages and renames

2.5.0 extended atomic save from stream wrappers to plain local paths, then restored the streaming writer underneath it. Local saves now stage through xlBookSave into an exclusively created sibling temp file and rename it into place, so the atomicity holds and the memory cost does not. Save time is unchanged. The staged file also carries the destination's existing permission bits, so replacing a 0600 workbook no longer widens it to 0644.

Atomicity on local paths changes three behaviours worth knowing before you upgrade. A symlink destination is replaced by a regular file instead of written through. An existing hard link is broken. Saving into a writable file inside a non-writable directory now fails instead of succeeding, because the rename needs the directory.

Typed writes stopped lying. An explicit data type that the value cannot satisfy is now rejected rather than silently stored as something else.

// 2.4.0: stored the string as text. 2.5.0: rejects, and names the cell it stopped at.
$sheet->write(0, 0, 'not a date', null, ExcelFormat::AS_DATE);

null still writes a blank cell under any data type, so bulk writeRow() and writeCol() calls over a typed column with gaps keep working.

2.6.0 is two lines on top of that, and one is breaking. ExcelFormat::borderDiagonalStyle() was wired to the diagonal direction rather than the line style it is named for. It now addresses the style, and the new ExcelFormat::borderDiagonal() gets and sets which diagonals are drawn. Code passing a BORDERDIAGONAL_* constant to the old method keeps running without error and quietly stops drawing its diagonal, so it is worth grepping for.

github.com/iliaal/php_excel

pdo_duckdb 0.5.0: the sandbox stopped charging by the row

The open_basedir sandbox re-latched itself once per row and compared the recorded basedir by hash. Under a long open_basedir that cost scaled with the string length, which is a strange thing for a per-row cost to depend on. It now re-latches once per fetched data chunk and compares by string.

A 400,000 row scan with a 223 character open_basedir went from 133 ns/row back to 51 ns/row. Bulk Appender::appendRow() went from 196 ns/row back to 96 ns/row.

The rest of the release is the sandbox itself getting harder to walk out of. DuckDB re-allowlists a non-empty temp_directory and any attached paths when external access is turned off, and those entries cannot be cleared afterwards, so the escalate sequence now clears temp, clears the sticky log_query_path and profiling_output writers, drops the path allowlists, and detaches out-of-basedir databases before flipping enable_external_access off and locking configuration. Re-narrowing open_basedir after that fails closed rather than leaving the wider policy in force.

One rendering bug is worth calling out because it is silent. A DECIMAL whose type has no integer digits rendered with a leading zero that DuckDB itself does not emit.

// DECIMAL(2,2): DuckDB renders .05, the driver rendered 0.05

That affected scalar cells since 0.4.1 and nested LIST, ARRAY, STRUCT, and MAP cells since the direct nested renderer landed. Prebuilt binaries now link DuckDB 1.5.5; a source build still works against the advertised 1.5.3 floor.

github.com/iliaal/pdo_duckdb

fast_uuid 0.6.0: a batch that reads the clock once

uuid_v7_batch() and uuid_v7_bin_batch() used to read the clock once per UUID. They now read it once per call, which is about 2.6x faster per UUID on aarch64. The v4 batch generators draw CSPRNG bytes for 64 UUIDs at a time instead of 16 bytes per UUID, worth another 6 to 8%.

$ids = uuid_v7_batch(100000);   // ~8 ms, all carrying the batch-start millisecond

The trade is stated in the release notes because it is observable: every UUID in one call carries the batch-start millisecond, so getDateTime() on the tail of a large batch can trail the wall clock by the batch duration. Values stay unique, sorted, and monotonic against the next single call.

The compat layer paid a cost in the other direction. Internal\ConstructionToken::Trusted used to skip the wrapper-class check, and it no longer does, so every compat wrapper validates its core on construction. That is one getVersion() call and a class-name comparison, and it makes construction about a third slower than 0.4.0: UuidFactory::fromBytes() drops from 1.81M to 1.21M ops/s on aarch64. I kept it. A wrapper that does not match its core is a bug that surfaces somewhere much less convenient.

0.6.0 also settled how far the compat layer follows ramsey/uuid. Every identity form now derives from toString(), as it does upstream, so getUrn(), getHex(), getInteger(), equals(), and compareTo() all follow a COMB codec's reshaped text rather than the network-order core. The one deliberate departure is GuidStringCodec, which reshapes the byte array only. Over 400 $guidFactory->uuid4() calls, ramsey/uuid 4.9.2 threw 190 times with "The byte string received does not contain a valid version" and emitted a wrong version nibble in the text 184 more times, leaving 26 clean. The same loop here returns 400 usable v4 GUIDs.

github.com/iliaal/fast_uuid

fastchart 1.7.0: limits, and one honest regression

Every documented resource and numeric limit is now enforced before valid chart state is replaced. Pie totals, graph-label aggregates, error-bar arrays, Venn sets, category labels, and scatter image-map strings used to validate after clearing, so a caught over-cap ValueError left you holding a wiped chart. Arc, Chord, and Network setNodes() and setLinks() throw on over-cap input instead of silently truncating it.

Two new INI settings bound memory that memory_limit never saw, because it lives outside the PHP allocator:

fastchart.max_render_pixels = 64M      ; PHP_INI_SYSTEM, bounds raster buffers
fastchart.max_image_cache_bytes = 64M  ; PHP_INI_SYSTEM, bounds retained decoded images

Caller-supplied SVG is now rejected above 65,536 elements, 262,144 attributes, or 256 nesting levels. renderToFile() accepts only local filesystem paths, because a stream wrapper cannot provide atomic replacement, and it preserves an existing destination's mode, revalidates open_basedir and staging identity at commit, and leaves the prior file under a recovery name when a post-install race prevents cleanup.

The performance line is mixed and I would rather write it down than round it off. Stock rolling indicators moved to linear-time extrema and statistics paths, and ordinary series are 2 to 33% faster. A stock series carrying a near-DBL_MAX outlier with a multi-thousand window costs about 4x the 1.6.0 setter time, because that series now goes through normalized sliding aggregates instead of an overflow-prone accumulator. Raster file output streams encoder bytes straight into the atomic destination, and in-memory raster output no longer keeps a second full-size pixel frame.

github.com/iliaal/fastchart

fastjson 0.7.0: ext/json parity, down to the error state

fastjson's promise is that you can swap it in for ext/json, and this release is mostly about the places where that wasn't quite true. fastjson_encode(), fastjson_file_encode(), and replacement encoding in fastjson_pointer_set() now publish the outer operation's final error state after a nested callback or destructor calls fastjson recursively. A decode of a string carrying both a backslash escape and invalid UTF-8 under JSON_INVALID_UTF8_IGNORE no longer rejects: "\/\xFFe" was reported as an unexpected control character and now decodes to /e, as json_decode() does.

fastjson_pointer_set() picked up three fixes that matter if you use it on documents you didn't write. It validates pointer syntax and traversal before serialising the replacement, so a malformed pointer no longer runs JsonSerializable callbacks first. It preserves untouched number lexemes byte for byte, so large integers, -0, and trailing-zero forms survive a set elsewhere in the document. And fastjson_pointer_get() now rejects a pointer whose traversed path is made ambiguous by duplicate object members rather than silently taking the first.

The performance work, measured against 0.6.0 on PHP 8.4 release builds, x86_64 unless the changelog notes aarch64:

Operation	Change
`fastjson_merge_patch()`, 2,000-key merge	~95% faster
Large clean-ASCII encode, 256 KiB to 1 MiB	32 to 66% faster
Tolerant decode on clean input	20 to 64% faster
Packed-array decode	~22% faster
`fastjson_pointer_set()`	42 to 66% faster
Top-level scalar encode	35 to 43% faster

One of those is a reversal. The exact-size preflight for very large strings now starts at 8 MiB rather than 1 MiB, because below that the second pass cost more than the reservation it saved: 75% slower on x86_64 and 160% slower on aarch64 for UTF-8 text at 1 MiB. The optimization was real and the threshold was wrong.

github.com/iliaal/fastjson

phpser 0.5.0: a signature is not a provenance proof

The signed decode path in phpser assumed that a validly signed frame came from phpser's own encoder, and used that assumption to skip work. It skipped the object pin, and it used add_new style inserts for assoc, object-property, and rowset schema keys on the grounds that the encoder would never emit a duplicate.

A valid HMAC proves key possession, not honest-encoder provenance. Anyone holding the key can hand the decoder a frame the encoder would never produce. A forged-but-validly-signed frame carrying a duplicate key could free an id-registered object on overwrite while a later back-reference still pointed at it, which is a use-after-free reachable by anyone who can sign. Objects are now pinned unconditionally for the decode pass, and the trusted paths use uniqueness-gated inserts.

Two more use-after-frees came out of the encoder, both through user hooks. A __serialize or __sleep hook that grows the array being walked through a by-reference alias reallocated the table under the element iterator; the walk now holds a reference so the write copy-on-write separates instead. Native serialize() still exhibits this on the same input. A nested hook that replaced a referenced __sleep() member name after phpser had borrowed the string pointer is the third, and the encoder now owns the selected property names until it finishes the object. Decoder work on crafted Zend hash collisions is bounded, so wire-controlled keys cannot turn an associative array into quadratic CPU.

The columnar format got better at the same time. TAG_TABLE deduplicates low-cardinality strings and equal packed-string vectors by content, which makes distinct-allocation rowsets 53% smaller and 44% faster to decode than igbinary on ARM. Table decode streams each column into the row arrays instead of materializing the columnar matrix first: on a 60,000 by 4 table, peak memory drops from 34.0 MB to 30.0 MB with no speed change, and a rejected frame never pays for the rows it claims.

github.com/iliaal/phpser

php_clickhouse 0.11.0: values that came back different

These are the kind of bug you don't notice until a number is wrong in a report.

Float32 reads round-tripped through %.6g, which drops significant digits. toFloat32(123456789) read back as 123457000. Reads now return the exact value the server sent, with the full binary expansion, so toFloat32(0.55) is 0.550000011920929. Inserting a float outside the column's range throws instead of storing ±INF.

A compression setting of 2 was silently downgraded to LZ4 rather than selecting ZSTD. The option now accepts 0/1/2, the strings "none"/"lz4"/"zstd", and bool, and throws on anything else. Bool inserts accept only true/false, 0/1, and those four values as strings; the string "false" previously stored true.

Map decoding produced PHP arrays with duplicate keys, because the duplicate check went through zend_hash_str_add_new(), which skips the existence test and appends a second bucket under the same key instead of reporting the collision. Associative decoding now rejects a Map whose entries would collapse onto the same PHP array key, and a new mode gives you the lossless form:

$rows = $ch->select('SELECT m FROM t', [], ClickHouse::MAP_AS_PAIRS);  // ordered [key, value] pairs

ClickHouseStatement joins cycle collection, so a statement holding an object cell stops leaking its rows until request shutdown. A failed TLS handshake stops leaking the peer certificate and its chain, about 4.4 KB per rejected connection. And selectStream() works on a result carrying an untyped NULL column when memory_limit is set, which php-fpm sets by default. On 32-bit PHP, protocol integers and DateTime values wider than zend_long come back as decimal strings instead of wrapping negative.

github.com/iliaal/php_clickhouse

mdparser 0.5.0: less memory, same output

The output buffer used to reserve an exact size for every document. It now seeds a roughly 1.25x reserve capped at 1 MiB, so ordinary documents reallocate less, sparse input stops reserving output it never produces, and dense input past the cap grows by doubling. Heading-anchor side buffers are released as each heading is flushed instead of held for the document. Adjacent AST text fragments are coalesced into one text node, which cuts the callback-driven array overhead that showed up on AST-heavy workloads.

toInlineHtml() got the worst of the old behaviour. It appended multiline content one byte at a time, dropped line-leading inline delimiters, and let its per-line sentinel surface inside code and LaTeX spans that crossed a line break. It now bulk-appends content runs and preserves both the delimiters and literal U+200B.

Two GitHub Flavored Markdown gaps closed. Options::github() enables alerts as well as footnotes, and a bare URL containing a percent sign autolinks: http://a.com/x%20y used to stop the scan at the percent and stay literal text. Fenced code whose info string entity-decodes to a language- prefix no longer gets a second one prepended, so language-php produces class="language-php".

The vendored md4c moved to master 10c0158, which lets the local code-span line-break patch go away now that upstream carries it and picks up a bounds guard on the table-alignment dash scan. Zend memory-limit bailouts now release md4c's libc allocations before the request aborts.

github.com/iliaal/mdparser

phonetic 0.4.0: constants that cannot be confused

bmpm() takes a name type and an accuracy, in that order:

function bmpm(string $string, int $name_type = BMPM_GENERIC, int $accuracy = BMPM_APPROX, string $language = ""): string

BMPM_APPROX was 1 and BMPM_EXACT was 2. BMPM_ASHKENAZI is 1 and BMPM_SEPHARDIC is 2. So bmpm($name, BMPM_APPROX), which is a natural thing to write and wrong, ran as an Ashkenazi encode and returned a plausible answer. Nothing rejected it because nothing could tell the difference.

The accuracy constants are now 10 and 20, disjoint from the name-type range, so the same call is rejected by argument validation. This is breaking only for code that hard-codes the numeric values 1 and 2 for the accuracy argument; code using the constant names is unaffected. Forcing $language = "any" also raises a ValueError now, since that is the default ruleset label rather than a language; pass an empty string for auto-detect.

The rest is BMPM performance and bounds. The final-rule merge sorts once instead of running an O(R²) insert-sort, BMPM_MAX_PREFIX_DEPTH drops from 16 to 6 to bound the prefix dual-encode fan-out, and phoneme-set growth uses overflow-safe allocation. One earlier optimization got reverted: routing 1 to 3 element compares through memcmp() cost 5 to 6% of encode time, so the rule-matching inner loops compare code points inline again. double_metaphone() stops encoding once both codes reach max_length, and the match helpers skip the second encode when the first operand is unencodable or the two operands are identical.

github.com/iliaal/phonetic

What a stabilization release actually costs

Across these nine changelogs there is almost no new capability. One border method, one set of interfaces, a few error-code constants, one lossless Map mode. The rest of it is a Float32 that finally comes back the way the server sent it, a signed frame trusted for exactly what a signature proves and nothing further, and a bmpm() accuracy constant that can no longer be mistaken for a name type.

The part I didn't expect when I started this cycle is how much of the performance work turned out to be the same job. Streaming the workbook save back, re-latching the sandbox per chunk instead of per row, reading the clock once per batch, moving the string preflight threshold from 1 MiB to 8 MiB, comparing three code points inline instead of through memcmp(). None of that is a new algorithm. It is the cost of correctness, found and paid down after the correctness landed. Some of it stays paid: compat construction in fast_uuid is a third slower on purpose, and a fastchart stock series with a near-DBL_MAX outlier costs 4x what it did. Those are the trades I would make again, and they belong in the changelog rather than in the rounding.

Malcolm X Is Not a Suffix

Ilia Alshanetsky — Sun, 12 Jul 2026 14:09:16 +0000

Parse Malcolm X with almost any name splitter and you get a suffix. X looks like a roman numeral, roman numerals are suffixes (John III, Henry VIII), so X becomes the suffix and the surname disappears. That's the kind of bug you only find once you already have a working parser, because it isn't a missing rule. It's two correct rules wanting the same token.

Last month I wrote about the casing fix in nameparser: the idea that a parser reading Jane Doe DDS should keep Doe as the surname and DDS as a credential, using letter casing as the signal that lowercasing throws away. Version 1.3.0 is the follow-up, and it is almost entirely about collisions like Malcolm X: tokens that two disambiguation rules both claim. nameparser is a maintained fork of the dormant theiconic/name-parser, by way of codebyzach/name-parser's PHP 8.3+ modernization; the contribution here is the casing and credential layer plus a confidence pass, not the parser core.

The credential that is also a name

JO ANDERSON PhD used to parse to first name J. Jo is a real short given name, but in all caps it also reads as a credential-run token, and the credential rule won. 1.3.0 keeps all-caps short given names intact beside a mixed-case salutation or credential, so Jo survives.

The mirror image is the credential that gets read as a surname. Jane DDS (a credential-only row with no comma) and John A. MD (an initial plus a credential) used to rewrite the trailing credential as the last name, because a token in the surname slot with nothing after it looks like a surname. Both now keep the credential in the suffix.

The collision gets worse with more than one credential. John Smith MD FACS used to keep MD and leak FACS into the name, because FACS is not in the dictionary and an unknown trailing token defaults to a name. Now a known credential anchors the tail and pulls the unknown one in with it, so both stay in the suffix. Parenthetical credentials were their own trap: Jane Doe (MD) used to parse (MD) as a nickname, since parentheses mark nicknames, and now reads it as a suffix. And a credential-only segment that lands before the given name, as in Smith, MD, John, is pulled out to the suffix so the first name stays John rather than becoming MD.

Casing is the tiebreaker for all of these, which means it fails exactly where casing carries no signal. Uniform all-caps registry data, or all-lowercase input, has nothing to disambiguate on, so an ambiguous trailing token defaults to being read as a credential. That's a hard limitation, not a bug, and it's why the library ships a confidence pass: getConfidence() flags a casing-undecidable row as ambiguous so it can go to a human instead of silently into your database wrong.

Word order that hides the surname

Surname-first input is its own minefield when a salutation and a credential sit on the same name. Dr. Kim Jong Un used to lose the surname to the title; Kim Jong Un, MD used to fall back to Western order. Both now keep surname Kim, and Dr. Kim Jong Un, MD correctly yields surname Kim, salutation Dr., and credential MD. The salutation and the credential were each pulling the parser back toward a different word order, and the fix is teaching it that a leading salutation and a trailing credential-only comma tail can coexist with a surname-first name.

The comma inside the nickname

A comma in a name usually means surname-first. So a comma inside a delimited nickname is a direct collision with the rule that reads commas as name-order markers. John (Bob, Jr) Doe and John 'Bob, Jr' Doe used to bisect on that inner comma and lose half the name. 1.3.0 keeps the nickname Bob, Jr whole, for bracketed, quoted, and custom multi-character delimiter pairs alike, and the same holds on the given-name side: Smith, John (Jack, Robert) keeps Jack, Robert intact.

Scripts with no casing at all

If casing is the signal, a script without upper and lower case has none. Wang, 李明 used to split 李明 into two initials, because the initials rule fires on short tokens and nothing told it these were not initials. 1.3.0 leaves caseless-script names intact as the first name. In the other direction, an elided surname particle like the one in 't Hooft used to read as an unterminated nickname or an initial; it now survives as the leading particle. Dutch honorifics (Dhr., Mevr., Mw.) also join the default salutation set, so Dhr. Jan de Vries reads the title as a salutation rather than a first name.

And the input that is trying to break you

A name parser sits directly on user-supplied strings, so an adversarial input is a real exposure, not a theoretical one. Kilobytes of unmatched quotes, 100 KB tokens of any case shape, megabyte-long rows: 1.3.0 parses all of them in linear time and bounded memory. Invalid-UTF-8 delimiter keys and empty whitespace sets that used to emit a compile warning on every parse are now ignored quietly.

Turning a wrong split into a review queue

Every collision above resolves on casing, and casing runs out of signal on uniform-case data. So the honest design isn't to pretend the parser is always right; it's to say when it's guessing. The confidence pass reads the same input the parser does and flags a row whose split hinges on a signal that is not there.

use Iliaal\NameParser\Parser;

$name = (new Parser())->parse('SMITH, JM');
$name->getConfidence();   // ['ambiguous' => true, 'notes' => [...]]
$name->getSource();       // 'SMITH, JM'  (the normalized input it judged)

SMITH, JM is exactly the case with no answer: with mixed case, Smith, JM splits JM into the initials J and M, because the mixed-case surname proves those are initials; all-caps SMITH, JM keeps Jm as a first name, because the caps could equally be a short given name. The parser has to pick one, and the confidence flag records that it had to. getSource(), new in 1.3.0, returns the normalized string the confidence was assessed against, so a batch importer can log precisely what it judged. The flag is advisory and opt-in; it never changes what parse() returns. On a million-row import, that is the difference between silently corrupting an unknown fraction of records and routing a known set of them to a person.

One caution the README states and this post repeats: ambiguous => false on an all-caps row is not a correctness guarantee. Clean credentials that are not also names (RN, PT, OD) are left unflagged on purpose, to keep review volume manageable, so a false there means "no name-colliding token," not "definitely right."

The seams where cases meet

None of these are new features. They're the boundaries between rules that were already there, the places where two disambiguation heuristics both reach for the same token. That's what this round of work looks like: not more cases, but the seams where cases meet. Casing decides most of them. Where it cannot, the confidence flag says so, and the row goes to review instead of into your data wrong.

composer require iliaal/nameparser

github.com/iliaal/nameparser

Failing Closed: What Shipped Across Seven PHP Extensions

Ilia Alshanetsky — Fri, 10 Jul 2026 13:24:45 +0000

ExcelBook::save() to a file:// path used to truncate your existing file before it finished writing the new one. If the write was short or got interrupted, you were left with neither the old file nor a complete new one. php_excel 2.4.0 fixes that: the write goes to a temp file and renames into place, so a failed save leaves your original intact.

That fix doesn't make a good changelog headline. It's also most of what shipped across seven of my PHP extensions in the last month. Some of it is new capability, a new Markdown engine, twelve more chart types, a columnar serializer, native JSON columns in ClickHouse. Most of it is the other kind of work: rejecting a bad value instead of storing it, throwing on the untrusted path instead of trusting it, failing a write cleanly instead of half-committing it. This is the second roundup in the series; the June one covered the version-floor drops. Here is what landed since.

mdparser 0.4.3: a new engine under the same API

mdparser swapped its entire parsing backend in 0.4.0. cmark-gfm is gone, replaced by md4c, a single-file streaming CommonMark parser compiled directly into the extension. The four render methods and the Options surface are unchanged; only the engine underneath is new. The swap brings clean CommonMark 0.31 conformance (652 of 652 spec examples) and drops the external cmark-gfm dependency entirely.

md4c also supports a set of dialects cmark-gfm did not, each opt-in and off by default: LaTeX math ( $inline$ and $$block$$), wiki links ([[target]]), spoilers, ==highlight==, super and subscript, and GitHub-style admonition blocks (> [!NOTE]) added in 0.4.1. Each surfaces as its own node type in toXml() and toAst().

use MdParser\{Parser, Options};

$html = (new Parser(new Options(latexMath: true, wikiLinks: true)))->toHtml($source);

The hardening that came with the rewrite is the part I care about more. 0.4.2 fixed a stack buffer overflow in the CommonMark XML serializer: an ordered list with a wide start number could truncate the tag, embed a NUL byte, and at the widest input read past a fixed 64-byte stack buffer. 0.4.3 closed an alt="..." breakout where raw HTML in image alt text was not attribute-escaped under unsafe: true. And the in-stream heading-anchor rewrite resolved the 0.3.0 limitation where a raw <h1> and a Markdown # heading could fight over the same id.

One honest trade: md4c exposes no source positions, so sourcepos and a handful of old cmark-only options are accepted for compatibility but inert.

github.com/iliaal/mdparser

fastchart 1.6.0: from 26 chart types to 38

fastchart 1.4.0 added twelve chart classes in one release, taking the catalog from 26 types to 38. The new set is mostly hierarchy and relationship charts: dendrogram, partition (icicle), chord diagram, network graph, arc diagram, circle packing, Venn diagram, violin plot, population pyramid, word cloud, pictogram, and a serpentine timeline. The two hierarchy charts feed from one setHierarchy() call.

$chart = new FastChart\Dendrogram(900, 600);
$chart->setHierarchy($root);
$chart->renderToFile('tree.svg');

1.5.0 was the performance release. A 4096-point scatter with per-point colors renders about 6x faster now that SVG color handles resolve through a hash table instead of a linear scan; renderPng() is about 40% faster after switching from adaptive to a fixed UP row filter at effectively unchanged file size; and dense SVG documents emit about 40% faster through dedicated integer color formatters. 1.4.0 also added seven StockChart indicators (VWAP, ZigZag, ATR, CCI, Williams %R, Aroon, standard deviation).

The vector PDF backend from 1.3.0 is still a v1. This round's PDF work was hardening, fully transparent colors that used to paint opaque, band-gradient alpha that got discarded, rather than the gradient support it still lacks.

github.com/iliaal/fastchart

php_clickhouse 0.10.0: JSON, Bool, and IPv6 columns, and a faster decoder

Three releases since 0.8.7. 0.8.8 added native JSON, Bool, and IPv4/IPv6 column read and write; a JSON insert takes a PHP array, object, or raw JSON string, and reads return the string or decode with JSON_AS_ARRAY / JSON_AS_OBJECT. 0.9.0 rewrote the decoder and insert-builder hot paths. 0.10.0 tightened correctness.

The perf work in 0.9.0 is the kind you only find with a profiler. Result decoding used to downcast each scalar column through dynamic_pointer_cast, an atomic refcount round-trip plus an RTTI walk; a callgrind attributed about 18% of decode instructions to that one cast. The integer, float, and string paths now use a direct static cast keyed on the column's type code. Numeric inserts build straight from the row-major input instead of transposing into a temporary PHP array first. Wide integer SELECTs decode about 25% faster; numeric-heavy inserts land 30 to 44% faster.

// FixedString payloads (IPv6, hash digests) read back at full width, trailing NULs kept
$rows = $ch->select('SELECT ip FROM sessions', [], ClickHouse::FIXEDSTRING_BINARY);

0.10.0's correctness pass is the fail-closed theme again: inserting PHP null into a non-Nullable JSON column now throws instead of silently storing an empty {}, and a clean server error (bad SQL, missing table) no longer reconnects and quietly discards your session's temp tables and SET settings.

github.com/iliaal/php_clickhouse

phpser 0.4.0: a columnar wire format for rowsets

phpser's wire format v2 (0.3.0) added a columnar layout for homogeneous rowsets. Instead of writing each row's keys and values, TAG_TABLE writes the column schema once, then each column as a typed run: packed longs, doubles, strings, or mixed. For the array-of-uniform-rows shape that cache and queue payloads usually are, that drops the per-row key overhead entirely. v1 payloads still decode.

$blob = phpser_serialize($rows);   // columnar automatically when rows share a schema
$rows = phpser_unserialize($blob);

0.4.0 made table encode a single row-major pass instead of an O(rows × cols²) per-column rescan (about 20% faster rowset encode on aarch64), and rowset decode about 24% faster by resolving dictionary strings against the engine's interned-string table. It also closed two issues on the untrusted decode path. A TAG_OBJECT_SLOTS payload now routes through __unserialize() when the class defines it, instead of installing raw property slots and running __wakeup(), closing an invariant-rebuild bypass. And a crafted __PHP_Incomplete_Class_Name property can no longer resurrect an attacker-chosen class name on a later decode.

The columnar path is automatic; you don't opt in. It only engages for homogeneous string-keyed rowsets, and a single row or a mismatched schema falls back to the general encoding.

github.com/iliaal/phpser

fastjson 0.6.0: JSON Pointer you can write to, and prebuilt binaries

The June roundup covered fastjson_pointer_get() and merge-patch. 0.5.0 completed the RFC 6901 surface with fastjson_pointer_set(), which sets a value by pointer and returns the re-serialized document, and fastjson_pointer_exists(), which distinguishes present-but-null from absent without materializing anything into PHP.

$updated = fastjson_pointer_set($json, '/user/email', 'new@example.com');

0.5.0 also started publishing prebuilt .so binaries for Linux glibc (x86_64, arm64) and macOS (arm64) on PHP 8.4 and 8.5 as release assets, so PIE installs the binary instead of source-building on those targets. 0.6.0 was hardening: a use-after-free when encoding an array that a nested JsonSerializable mutates through an aliasing reference (the array is now copied first, as ext/json does), and stack-exhausting nesting in pointer_set rejected up front instead of crashing.

github.com/iliaal/fastjson

php_excel 2.4.0: bulk reads and a hardening pass

2.3.0 added bulk read paths. readRange() pulls a rectangular block of cells into a 2D array in one call instead of per-cell PHP dispatch, readSparseRow() and readSparseCol() return only the occupied cells keyed by their original index, and loadPartially() reads a single sheet's row slice without loading the rest of the workbook.

$block = $sheet->readRange(0, 999, 0, 25);   // a 1000 x 26 region in one call

2.4.0 is the atomic-save fix from the top of this post plus the rest of the fail-closed pass: load() rejects a buffer above UINT_MAX instead of truncating a payload over 4 GiB, writeRow() and writeCol() validate every value before writing any cell instead of committing half the row and then failing, and inverted ranges (first > last) are rejected instead of stored as garbage coordinates. One security tightening: excel.license_key and excel.license_name are now PHP_INI_SYSTEM, so a per-request ini_set() or .user.ini can no longer overwrite the commercial license in a shared pool.

github.com/iliaal/php_excel

fast_uuid 0.4.0: binary and batch generators, and ramsey/uuid parity

0.3.0 added binary and batch generation. The binary generators (uuid_v4_bin(), uuid_v7_bin(), and the rest) return the raw 16 bytes with no canonical formatting, for a BINARY(16) column or a wire format with no string round-trip. The batch generators build many at once and amortize the per-call cost; v7 batches stay monotonic within the call.

$ids = uuid_v7_bin_batch(1000);   // 1000 raw 16-byte v7 UUIDs, monotonic

Most of 0.3.0 and 0.4.0, though, is ramsey/uuid compatibility correctness. The compat TimestampFirstCombCodec used a byte rotation instead of ramsey/uuid's first-6/last-6 swap, so a COMB written by ramsey/uuid decoded to a different UUID; the layout now matches, and COMB columns interop. Fields::getTimestamp() truncated v1 and v6 timestamps on 32-bit PHP; it now rebuilds them exactly as a hex string. Canonical parsing also runs about twice as fast through a 256-entry nibble lookup table.

One breaking change to note if you catch it: UnsupportedOperationException now extends \LogicException instead of \RuntimeException, matching ramsey/uuid 4.x.

github.com/iliaal/fast_uuid

The unglamorous majority

The features are the headline: a new Markdown engine, twelve more chart types, a columnar serializer, native JSON in ClickHouse. But count the lines in these seven changelogs and most of them are the other kind: a value rejected instead of stored, a write that fails cleanly instead of half-committing, a throw on the untrusted path instead of a silent coercion. That work never reads well in release notes. It's the difference between an extension you benchmark once and one you leave running.

I objected to deprecating metaphone(). Then I read the RFC.

Ilia Alshanetsky — Wed, 01 Jul 2026 13:52:15 +0000

A while back a proposal landed on the PHP internals list: deprecate metaphone(). My first reaction was the reflex of someone who has spent years as a PHP release master. Leave the old string functions alone, people depend on them, deprecation churn is its own tax. I was ready to argue against it.

Then I read the reasoning and went looking at what phonetic name matching is actually supposed to do in 2026. I changed my mind. metaphone() should go. What surprised me was not that the function is dated. It was how far the field had moved while PHP core stood still, and how weak the replacement path the RFC points at really is. So I built the replacement I wish it had recommended.

metaphone() is the oldest, least accurate version of an idea that kept evolving

The RFC is right, and here is the short version of why. The metaphone() in core is the original 1990 algorithm: English-only, single-key, tuned for one accent of one language. It was superseded twice. First by Double Metaphone (Lawrence Philips, 2000), which emits a primary and an alternate key so ambiguous pronunciations still match. Then by Metaphone 3, which corrects hundreds more edge cases.

Core shipped the first version and never moved. soundex() is older still, a 1918 patent. Both encode a single English-centric key, and both fall over the moment a name crosses a language boundary or carries a transliteration variant. For the one job these functions exist to do, collapsing names that sound alike but are spelled differently, they are the weakest tools in the drawer.

So the deprecation is defensible. Maintaining the least accurate member of a whole family of algorithms, in C, in core, when most applications can do better elsewhere, is not a good use of anyone's time. I came around to that part.

"Use a userland library" is the wrong replacement

Here is where I part ways with the RFC. Its answer to "what do I use instead" is that there are actively maintained Composer libraries implementing Double Metaphone. That is true, and it is also the wrong instinct.

Phonetic encoding is a hot inner-loop operation. You run it over every name in a dataset, sometimes millions of them, to build a match index you can query later. A pure-PHP implementation pays interpreter overhead on every character of every name. The honest replacement for a native C string function is another native C string function, not a userland reimplementation that is correct but an order of magnitude slower. That performance gap is the entire reason the code lived in core to begin with.

That is what moved me from "argue against the RFC" to "agree with the RFC, then go build the thing it should have recommended." The result is phonetic, a native extension that ships the five encoders core never had, plus the comparison helpers that answer the only question most people actually ask.

Double Metaphone: the successor you can actually ship

Double Metaphone is the algorithm the RFC's own rationale reaches for first, and it is the natural default. It returns two keys, a primary and an alternate, so a name with more than one plausible pronunciation matches on either.

double_metaphone("Schwarzenegger");   // ['primary' => 'XRSN', 'alternate' => 'XFRT']
double_metaphone("Catherine", 3);     // ['primary' => 'K0R',  'alternate' => 'KTR']

The RFC names Metaphone 3 as the other successor. Worth knowing before you reach for it: the Metaphone 3 reference implementation is a commercial product, sold as source for $240, not free software. An older 2009 build sits under a BSD license inside OpenRefine, minus years of accuracy corrections. Double Metaphone is the newest variant you can actually vendor into an open project, which is why it, and not Metaphone 3, is what belongs within reach of every PHP app. My implementation is clean-room from the published algorithm, with Apache Commons Codec used only as a parity oracle for the test vectors.

Beider-Morse: matching across languages, and the GPL trap I had to dodge

Moskowitz and Moskovitz are one surname through two transliterations. Иванов is a name most encoders will not touch. Beider-Morse Phonetic Matching handles both, because it is language-aware. It detects, or is told, the source language family, then applies the right transliteration rules for Slavic, Germanic, Hebrew, and Romance names.

bmpm("Garcia", BMPM_SEPHARDIC, BMPM_EXACT);   // "garsia|gartSa"
bmpm_match("Moskowitz", "Moskovitz");          // true

The hard part is not the code, it is the data. BMPM is thousands of rules, and every obvious source for those rules is GPL. The canonical Beider-Morse PHP reference is GPL-3.0. abydos, the popular Python phonetic library, is GPL-3.0 specifically because it ported that same rule data. Copy either into a BSD project and the whole project turns GPL with it.

The escape is Apache Commons Codec, which ships the identical rule tables under Apache-2.0. I vendored the data from there, kept its license header, and added an Apache-2.0 section to the extension's LICENSE. Same data, clean license, and Commons Codec doubles as the parity oracle, so I know the output matches the de-facto reference. The lesson generalizes past this one extension: with phonetic algorithms, the data carries the license, not the code you wrap around it.

One honest caveat. BMPM is slow. It runs language detection and three rule passes over the input, so it costs roughly 60 times a Double Metaphone call, around 91,000 names a second on my machine. You pick it for recall, not throughput. When you already know the language, passing it explicitly skips detection and buys some of that back.

Daitch-Mokotoff Soundex: the genealogy standard

If you are matching Eastern-European or Ashkenazi surnames, this is the field standard, and core never had it. Daitch-Mokotoff was built for exactly that problem, and it is what genealogy databases actually run. It emits a set of six-digit codes, branching on ambiguous letters so one name can carry several codes at once.

dm_soundex("Auerbach");                     // ['097400', '097500']
dm_soundex_match("Moskowitz", "Moskovitz"); // true

Its rule data comes from Apache Commons Codec too, for the same licensing reason as BMPM.

NYSIIS and Match Rating: two lighter English encoders

Both are cheap single-key encoders for American and English names, useful as a second opinion or an alternate index key. NYSIIS (New York State Identification and Intelligence System) is tuned for American surnames and returns one key. Match Rating Approach (Western Airlines, 1977) produces a compact codex and, unusually, ships its own similarity test instead of relying on key equality.

nysiis("Larson");            // "LARSAN"
nysiis("Larsen");            // "LARSAN"  (same key)
match_rating("Catherine");   // "CTHRN"

Both are clean-room from their published specs. They are the fastest encoders in the set, cheap enough to run as a second key alongside Double Metaphone when you want a little more recall without paying BMPM's cost.

The part I use most: the comparison helpers

The real day-to-day question is never "encode this name." It is "do these two names sound alike," and every algorithm answers it differently. That difference is where userland code quietly gets phonetic matching wrong.

Double Metaphone gives two keys; you match on primary agreement, weaker if only an alternate crosses. Daitch-Mokotoff and BMPM give sets; you match on intersection, not equality. Match Rating has a length-and-rating threshold that plain codex comparison skips entirely. Get that logic wrong and you either miss real matches or wave through garbage. So the extension ships one comparison helper per algorithm, each encoding the correct test for that encoder:

double_metaphone_match("Catherine", "Kathryn");   // 2  (primary keys agree)
double_metaphone_match("Vagner", "Wagner");        // 1  (only an alternate crosses)
dm_soundex_match("Moskowitz", "Moskovitz");        // true
bmpm_match("Peterson", "Petersen");                // true
nysiis_match("Smith", "Schmit");                   // true  (both SNAT)
match_rating_compare("Catherine", "Kathryn");      // true

double_metaphone_match() returns 2, 1, or 0, so you can rank match strength instead of treating it as a coin flip. The set-based helpers return a bool on intersection. match_rating_compare() applies the threshold the algorithm actually specifies. You call one function and get the right answer for that encoder, rather than reimplementing set intersection in a loop and getting the edge cases subtly wrong.

For a one-off check, that is the whole API. For repeated lookups against a fixed corpus, encode once and index the keys, then query by encoded value instead of comparing pair by pair:

$index = [];
foreach ($records as $id => $name) {
    foreach (dm_soundex($name) as $code) {   // index every code in the set
        $index[$code][] = $id;
    }
}
$hits = $index[dm_soundex("Moskovitz")[0]] ?? [];

Which one do I reach for?

Double Metaphone as the fast general-purpose default. BMPM when names cross languages or scripts and you can afford the cost. Daitch-Mokotoff for Eastern-European and Jewish genealogy, where it is the standard. NYSIIS or Match Rating as a cheap second key. The relative costs matter when you are encoding at scale:

encoder	relative speed	strongest for
`match_rating()`	fastest (0.24x)	English names; ships its own similarity test
`nysiis()`	fast (0.42x)	American and English surnames
`double_metaphone()`	fast (1.0x baseline)	general Latin-script names
`dm_soundex()`	middle (~2.3x)	Eastern-European and Ashkenazi surnames
`bmpm()`	slowest (~60x)	cross-language and transliteration variants

Two limits worth stating plainly. These are heuristic, culture-bound encoders. They target Latin-script names, and for BMPM and Daitch-Mokotoff, specific language families. They are not a universal global-name solution. And Greek-script input has a known limitation: capitals are not lowercased, because the context-sensitive final-sigma rule cannot be expressed as a point-wise case map, so Greek names need to be passed lowercased or romanized.

Where I landed

I set out to defend metaphone() and finished by agreeing it should be deprecated. The function is the weakest version of an idea that produced far better tools over the thirty years since. The flaw in the deprecation story is not the deprecation. It is pointing at a slower userland library as the replacement for a native one. Phonetic encoding runs in a hot loop, so it belongs in C.

The five encoders core never shipped are now one native extension, with the "do these sound alike" helpers most callers actually need:

pie install iliaal/phonetic

github.com/iliaal/phonetic

I Forked a Dead PHP Name Parser Because It Couldn't Tell a Credential From a Surname

Ilia Alshanetsky — Wed, 24 Jun 2026 19:32:57 +0000

Here is a bug in a name-parsing library I use at work:

// theiconic/name-parser
$name = $parser->parse('Jane Doe DDS');
$name->getLastname();    // "Dds"
$name->getMiddlename();  // "Doe"

The dental credential is now her last name. The real surname got shoved into the middle-name field. Every row with a trailing credential and no comma had some version of this, and in a list of clinicians that is most of them.

The library is theiconic/name-parser, a small, genuinely useful PHP package that splits a full-name string into salutation, first name, initials, last name, suffix, and nickname. I use it at work. It does the boring parts well. But the upstream repo went quiet around 2020, and bugs like the one above never got fixed.

So I forked it. Today I'm releasing iliaal/nameparser, a maintained fork that fixes the credential handling, adds a confidence signal for the cases it genuinely can't decide, and targets PHP 8.3+. Most of the fix is unglamorous boundary work. One part of it rests on a single idea worth writing down: the parser was throwing away the one signal that tells a credential from a name.

When the Credential Is Also a Name

There are two ways a credential ends up in the wrong field, and they are not the same bug.

The easy one is Jane Doe DDS. DDS is never a name, so the only question is where the token boundary sits. Upstream, with no comma to anchor it, takes the last token as the surname and never asks whether it is actually a trailing credential. The fork checks, recognizes DDS as a suffix, and keeps Doe:

// fork
$name = $parser->parse('Jane Doe DDS');
$name->getLastname();  // "Doe"
$name->getSuffix();    // "DDS"

The hard one is when the token is both a name and a credential. Ma is a surname. MA is a master's degree. Do is a Vietnamese surname and a doctor of osteopathic medicine. Feed upstream a comma form where the given name is one of these and the name disappears:

// theiconic/name-parser
$name = $parser->parse('Smith, Ma');
$name->getFirstname();  // ""
$name->getSuffix();     // "MA"

The given name Ma was stripped into the suffix as the credential MA. The field is now empty. Nothing threw, nothing warned; a person's first name was deleted because it collided with a degree abbreviation.

Casing Is the Signal Your Parser Throws Away

Upstream keys every token through strtolower() before matching it against its credential dictionary. Once Ma becomes ma, it matches MA and gets stripped. The piece of information that would have saved it, the capital pattern, was deleted on the first line.

People write credentials in capitals and names in title case. Smith, Ma is a person named Ma. Smith, MA is someone with a master's degree and no recorded first name. The capitalization is not decoration; it is the writer's own distinction between the two, and lowercasing throws it away before anything looks at it.

The fork stops throwing it away. An ambiguous token, one that collides with both a name and a credential, is treated as a credential only when it is written in all caps. Title case or lower case keeps it as a name:

// fork
$parser->parse('Smith, Ma')->getFirstname();  // "Ma"   title case, kept as a name
$parser->parse('Smith, MA')->getFirstname();  // ""     all caps, read as the credential MA

The same idea fixes a second class of mangling. Under all-caps input there is no case left to mark a two-letter token as a set of initials, so upstream guesses wrong and splits a short given name down to one letter:

$parser->parse('JO ANDERSON')->getFirstname();
// upstream: "J"   (JO read as the initial J)
// fork:     "Jo"

Same dictionary, same tokens. The difference is that casing now decides the ambiguous cases instead of being discarded before the decision is made.

This is a small change with a large blast radius, because the failure was silent. Upstream didn't throw. It wrote a wrong field and moved on, which is exactly the kind of bug you find six weeks later in a report nobody can reconcile.

When Casing Can't Decide: A Confidence Signal

Casing only works when there is casing to read. Uniform-case input, an all-caps legacy export or an all-lowercase dump, carries no signal at all. NGUYEN, VI could be the surname Nguyen with the given name Vi, or the surname Nguyen with the credential VI, and nothing in the string tells you which. The parser has to pick a default, and a default is a guess.

For a one-off parse, a guess is fine. For a batch import of a few hundred thousand person records, a silent guess is a data-integrity problem you won't notice until it matters. So the fork adds an advisory pass that tells you when the input was undecidable:

use Iliaal\NameParser\Confidence;

$result = Confidence::assess('NGUYEN, VI');
// [
//   'ambiguous' => true,
//   'notes' => ["'VI' could be a name or a credential; input casing is uniform"],
// ]

if ($result['ambiguous']) {
    // route this row to manual review instead of trusting the split
}

The same signal is available on the parsed result, derived from the same input the parser saw:

$parser->parse('NGUYEN, VI')->getConfidence();  // ['ambiguous' => true, 'notes' => [...]]

getConfidence() is read-only. It doesn't change what parse() returns; it's a second opinion you opt into. A mixed-case Nguyen, Vi stays unflagged, because the title-case Vi already resolved to a given name. The flag fires only when the casing genuinely could not decide.

Here is the limitation, stated plainly, because the post that hides it is the post you stop trusting: this is a heuristic keyed on casing, and uniform-case data has no casing to key on. On an all-caps dataset, an ambiguous trailing token still reads as a credential by default. What the confidence pass buys you is a queue. It flags the uniform-case rows where the token plausibly collides with a real name, so you can review those instead of trusting all of them. It does not flag clean credentials that are not also names, RN, PT, OD, because flagging every one of those would drown the review queue on exactly the all-caps data where review matters most. An ambiguous => false on all-caps input is not a correctness guarantee. It means no name-collision was detected, not that the split is definitely right.

What Else Changed

The casing work is the headline, but a maintained fork is also a place to fix the smaller things that accumulate in a dormant library.

The toArray() method returns every part under a fixed key set, with an empty string for any part that is absent. Upstream's getAll() omits empty parts and varies its keys, so consuming it means existence-checking every field. toArray() is a stable shape you can hand to json_encode() or a DTO without guards:

$parser->parse('Dr. Jane A. Doe DDS')->toArray();
// [
//   'salutation' => 'Dr.', 'firstname' => 'Jane', 'initials' => 'A.',
//   'middlename' => '', 'lastname_prefix' => '', 'lastname' => 'Doe',
//   'suffix' => 'DDS', 'nickname' => '', 'given_name' => 'Jane A.',
//   'full_name' => 'Jane A. Doe',
// ]

The credential dictionary grew teeth for healthcare data specifically. Beyond the standard academic and professional suffixes, the fork adds nursing and allied-health credentials, RN, NP, PharmD, APRN, PA-C, OTR/L, and thirty-odd more, mined by frequency from the NPI registry. If you parse clinician names, a trailing credential no longer leaks into the first name.

A handful of robustness fixes round it out. An unclosed nickname delimiter no longer swallows the surname: upstream parses John (Bob Smith to a last name of John, the fork keeps Smith. A lone bracket or quote token returns an empty Name instead of crashing parse() with a TypeError. Config setters take effect on a reused parser even when called after the first parse(). Everything after a second comma is kept as a middle name, so Smith, John, Robert keeps Robert while Smith, MD, PhD still strips to suffixes.

The fork targets PHP 8.3+ and is tested through 8.5, runs clean under PHPStan level 9, and the full upstream getter surface is unchanged. It's additive. If you were on the original, the methods you called still return what they returned, minus the credential bug.

Credit Where It's Due

This is a fork, not original work, and the lineage matters. The parser core is The Iconic's. The modernization to PHP 8.3+ that I built on came from Zachary Miller's fork. What I added is the casing-and-credential layer, the confidence signal, and the robustness fixes above. I'm standing on two other people's work and I'd rather say so than pretend the whole thing sprang from nothing.

Install it:

composer require iliaal/nameparser

The repo, with the full changelog and the all-caps limitation documented in the README, is at github.com/iliaal/nameparser. If you parse names from professional or registry data and you have ever found a credential sitting in a surname column, this is the fix.

pdo_duckdb: DuckDB for PHP, Behind the PDO API You Already Know

Ilia Alshanetsky — Fri, 19 Jun 2026 18:36:37 +0000

DuckDB is the closest thing the analytics world has to SQLite. It runs in-process, needs no server, reads and writes a single file, and chews through columnar aggregate queries that would make a row-store sweat. PHP has shipped PDO_SQLite in core for twenty years. Until now it had no equivalent for DuckDB.

So I wrote one. pdo_duckdb is a native PDO driver. You open a DuckDB database with a DSN, prepare statements, bind parameters, and iterate results through the same PDO API you already use for SQLite, MySQL, and PostgreSQL.

$db = new PDO('duckdb:/path/to/analytics.duckdb');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = $db->prepare('SELECT region, SUM(amount) AS total FROM sales WHERE year = ? GROUP BY region');
$stmt->execute([2026]);
foreach ($stmt as $row) {
    printf("%s: %s\n", $row['region'], $row['total']);
}

This is also the first PDO driver I've written in over fifteen years. I was one of the original authors of PDO back in the PHP 5.1 days, so coming back to that extension surface was equal parts muscle memory and culture shock.

Why a PDO Driver and Not Another FFI Binding

You can already reach DuckDB from PHP today. It has a C API you can drive through FFI, and there's always shelling out to the CLI. Both work. Both also hand you a brand-new API surface, manual lifetime management, and a data layer that looks nothing like the rest of your application.

PDO is the abstraction PHP developers already have in their fingers. A PDO driver means prepared statements, parameter binding, the exception error mode, fetch modes, and transactions all behave the way they do for every other PDO backend. Your repository classes and query builders transfer unchanged. The driver is written in C against DuckDB's C API, so there is no FFI boundary at runtime and no per-call marshalling happening up in PHP.

To be fair to FFI, it has its place. If you need a DuckDB capability the PDO surface doesn't expose, FFI hands you the entire C API and gets out of the way. pdo_duckdb makes the opposite trade on purpose: less breadth, in exchange for fitting into code you've already written.

DuckDB in One Paragraph, If You Haven't Met It

DuckDB is an in-process analytical (OLAP) database. The relationship to ClickHouse or Snowflake is roughly what SQLite is to Postgres: same SQL you know, no server to run, embedded directly in your process. It is columnar and vectorized, built for scans and aggregations over a lot of rows rather than single-row OLTP traffic. The DSN tells the driver which database to open:

duckdb:/path/to/database.duckdb   # file-backed database
duckdb::memory:                   # in-memory database
duckdb:                           # in-memory database (empty path)

An in-memory database is scratch space that vanishes when the connection closes; a file-backed one persists to disk. DuckDB's own extensions load through ordinary SQL, with no special driver API to learn:

$db->exec('LOAD json');                     // bundled extensions load offline
$db->exec('INSTALL httpfs; LOAD httpfs;');  // downloadable extensions

Reading Parquet, querying a CSV in place, or pulling a file over HTTP is a LOAD away, all through the same $db->exec() you would use for any statement. The driver doesn't wrap or re-expose any of it. DuckDB's SQL surface is the API.

Bulk Loading: The Appender

Row-by-row INSERT is the wrong way to push a lot of data into a columnar store, and DuckDB knows it. The driver exposes DuckDB's native appender through PDO::duckdbAppender(), which streams rows into a table far faster than a loop of prepared INSERT statements.

$db->exec('CREATE TABLE events (id INTEGER, name VARCHAR, ts TIMESTAMP)');

$app = $db->duckdbAppender('events');      // optional 2nd arg: schema name
foreach ($rows as $r) {
    $app->appendRow($r['id'], $r['name'], $r['ts']);
}
$app->flush();                              // or $app->close() to finalize

appendRow(...$values) takes one argument per column, left to right, and returns the appender so calls can chain. PHP null, bool, int, float, and string map to DuckDB values and get cast to the target column types. This is the one place the driver steps outside the standard PDO surface, and it earns the exception. Bulk ingestion is exactly where the row-at-a-time PDO model leaves the most performance on the table, so it's the one spot worth a driver-specific method.

The Parts of PDO That Don't Map Cleanly

This is the honest section. DuckDB is not MySQL, and a faithful driver has to refuse a few things rather than fake them.

lastInsertId() is not supported. DuckDB has no implicit rowid, so there is nothing honest to return. If you need generated keys, use a sequence and currval().

setAttribute(PDO::ATTR_AUTOCOMMIT, false) is rejected. DuckDB is autocommit-by-default with no session-level toggle, so instead of pretending otherwise, the driver points you at beginTransaction() for explicit transactions. From there commit() and rollBack() map onto DuckDB's COMMIT and ROLLBACK.

Placeholders get rewritten. Positional ? and named :name parameters are both supported, and PDO rewrites them to DuckDB's native $N form. That creates one sharp edge: because : introduces a named placeholder, an inline STRUCT or MAP literal inside a prepared query needs a space after the colon. Write {'k': 1}, not {'k':1}, or the parser reads :1} as a parameter and gets confused.

Types come back predictably, with one rule worth internalizing. Integers up to 64-bit signed arrive as PHP int, FLOAT and DOUBLE as float, and BLOB as a binary string. Everything else, VARCHAR, the DATE and TIME and TIMESTAMP family, DECIMAL, the wide HUGEINT and UBIGINT integers, and DuckDB's nested types, comes back in its canonical string form. That keeps values lossless when they wouldn't fit a native PHP scalar, at the cost of a cast on your side when you want a number out of a HUGEINT column.

Results are materialized, for now. execute() buffers the full result set in memory before PDO begins fetching. For the analytical queries DuckDB is built for that is usually fine, but a SELECT that returns millions of rows is bounded by available memory rather than streamed row by row. True streaming through DuckDB's pending-result API is the next thing on the list.

One behavior goes the other way, in your favor. When open_basedir is set, the driver disables DuckDB's SQL-level external file access: read_csv, COPY, ATTACH, httpfs, and the rest. Without that, a single COPY ... TO '/somewhere/outside' would punch straight through the sandbox open_basedir is supposed to enforce. The restriction holds at the SQL layer, not just for the path of the database file itself.

What Writing a PDO Driver Looks Like in 2026

The PDO driver model itself has barely moved since I last touched it. You fill in a handful of method tables, hang your connection state off the driver object, and PDO drives the rest. What changed is everything around it.

On PHP 8.4 and up, PDO::connect('duckdb:...') returns a Pdo\Duckdb subclass instance, and duckdbAppender() lives on that subclass. With new PDO('duckdb:...'), and on PHP 8.1 through 8.3, the method is reachable on the base object directly. PHP 8.5 starts emitting a deprecation when you call a driver-specific method on the base PDO class, so on 8.4 and newer you'll want PDO::connect(). The driver supports both paths; the subclass is just the cleaner one going forward.

The part that actually cost me a release was the link line. DuckDB ships as a C++ library with a C API bolted on top. The driver is C. The prebuilt Linux binary in 0.2.0 loaded fine on my machine and then died on a clean host with undefined symbol: _ZTVN10__cxxabiv120__function_type_infoE, the vtable for a C++ ABI type that was supposed to be baked into the binary. The bundled DuckDB C++ runtime was never getting statically linked, because the gcc C driver silently ignores -static-libstdc++, a flag it treats as g++-only. So the module quietly depended on a libstdc++ the target box didn't ship. 0.2.1 links the static libstdc++ and libgcc_eh in explicitly, and the Linux binary is genuinely self-contained now. macOS and Windows were never affected, which is its own special way to lose an afternoon chasing the wrong platform.

Distribution is the other thing that improved while I was away. On Linux x86_64 and arm64, macOS on Apple Silicon, and Windows x64, PIE downloads a self-contained prebuilt binary with no DuckDB install and no build toolchain required:

pie install iliaal/pdo_duckdb

On anything else it falls back to a source build that needs libduckdb and duckdb.h. The last time I shipped a PDO driver, this would have been a PECL package and a paragraph of phpize instructions for the reader to follow. Prebuilt binaries as the default install path is the single biggest quality-of-life change in PHP extension distribution since I started writing them.

Where It Stands

pdo_duckdb is an early release, and I'd rather say so than oversell it. The query path, the appender, parameter binding, transactions, and type decoding all work and are covered by tests. Streaming is the main thing still on the bench, and the type-mapping surface will keep growing as people push real workloads through it. I haven't published benchmarks, because the speed here is DuckDB's and the driver's job is to stay out of its way.

If you've wanted DuckDB's analytical engine reachable from PHP without learning a new client API or hand-rolling FFI, this is that, sitting behind the PDO surface you already know.

pie install iliaal/pdo_duckdb

github.com/iliaal/pdo_duckdb

Lowering the Floor: What Shipped Across Five PHP Extensions

Ilia Alshanetsky — Tue, 16 Jun 2026 17:43:07 +0000

Most libraries raise their minimum PHP version over time. Drop 8.1, require 8.2, then 8.3, because every release you can assume lets you delete a pile of compatibility shims. This round I went the other way. php_excel, fastchart, and fastjson now build on PHP 8.1, phpser dropped to 8.2, and all four had required 8.3 a release ago. php_clickhouse already runs on everything from 7.4 up, so it sat this one out.

The reason is mundane but worth stating: for a native extension, the minimum PHP version is a packaging decision, not a language-feature decision. None of these extensions needed an 8.3-only engine API. The floor was set high because that was the version I built and tested against first, and lowering it just meant wiring the older versions into CI and fixing whatever broke. A shop pinned to 8.1 on a long-term-support distro gets the same speedups as one on 8.5. That's the whole point of shipping a C extension instead of a Composer package.

Here is what else landed since the last set of releases.

php_excel 2.2.0: a write mode that can't be tricked into a formula

php_excel 2.2.0 lowers its floor to PHP 8.1 and adds a cell write mode that makes spreadsheet formula injection something you opt out of by accident rather than into. The headline is ExcelFormat::AS_TEXT.

Write a user-controlled string that starts with =, and php_excel promotes it to a live formula, the same trick behind spreadsheet-injection attacks once the file is opened. The usual mitigation is to remember to prefix every untrusted value with a quote. AS_TEXT writes the value verbatim instead: no leading-quote stripping, no implicit formula promotion, no numeric coercion.

// Untrusted input written exactly as given, never evaluated as a formula
$sheet->write($row, 0, $userInput, null, ExcelFormat::AS_TEXT);

The implicit "leading = becomes a formula" promotion also got narrowed in 2.2.0. It now fires only when you pass no data type at all. If you explicitly pass a type such as AS_NUMERIC_STRING, that type is honored instead of being silently overridden.

The release before it, 2.1.0, added libxl 5.2.0 support, which surfaces the data validations stored in an xlsx file. ExcelSheet::dataValidationSize() returns the count and ExcelSheet::dataValidation($index) reads one back as an associative array, so you can inspect the dropdowns and constraints a file was authored with rather than only writing new ones. The rest of 2.2.0 is a long list of boundary fixes: named-range and autofilter methods whose declared parameter order did not match the implementation, so named-argument callers got rows and columns crossed, are now correct.

github.com/iliaal/php_excel

php_clickhouse 0.8.7: stream a file straight into ClickHouse

php_clickhouse picked up a streaming bulk loader in 0.8.5 and a large memory-safety pass in 0.8.6, with 0.8.7 restoring the PHP 8.3 Windows builds. The loader is the feature most people will reach for.

insertFromStream() parses a TSV or CSV file, or any readable PHP stream, and INSERTs it in batches without ever materializing the whole file in PHP memory. The parser is C++ and handles TSV escapes and RFC 4180 CSV quoting, including embedded quotes, commas, and CRLF inside quoted fields.

$ch->insertFromStream(
    'events',
    ['ts', 'user_id', 'event'],
    fopen('events.tsv', 'r'),
    'TSV',
    50000          // rows per batch
);

The 0.8.6 hardening pass is less visible but matters more if you run this in production. A Map column read could leave the result row holding a freed array, a use-after-free that crashed when the row was later iterated or json_encoded. Cloning a ClickHouse object corrupted the heap; it now throws instead. And setDatabase() now rebuilds the connection with the new default, so the switch survives a reconnect rather than silently reverting to the database you passed the constructor. Several of those were the kind of bug that only shows up under a specific reconnect-or-retry sequence, which is exactly when you least want a dangling pointer.

github.com/iliaal/php_clickhouse

fastchart 1.3.0: vector PDF output

fastchart 1.3.0 can render any of its chart types to a vector PDF, and 1.2.0 lowered the floor to PHP 8.1 and exposed structured hot-spot data for image maps.

PDF output goes through the same primitive layer as the SVG path, so every chart type renders as real vector geometry with no rasterization. Text flattens to glyph outlines; arcs and ellipses approximate with cubic Béziers. It's opt-in at build time with --with-pdfio, which links a system pdfio statically, so the runtime dependency set does not change. Without the flag the PDF methods throw and the PDF tests skip.

$chart->renderToFile('report.pdf');   // or: $pdf = $chart->renderPdf();

This is a v1, and I'll state the limitations rather than hide them: gradient fills fall back to solid, raster background images are dropped, and alpha is ignored so fills render opaque. For the report-and-dashboard use case that PDF output exists for, that's usually fine; if you need gradients today, render to PNG.

The other 1.2.0 addition is getImageMapAreas(), which returns the chart's clickable regions as structured data (shape, coordinates, href, tooltip, index) instead of the pre-baked HTML that getImageMap() emits. If you build your own overlays or generate links yourself, you no longer have to parse HTML to get the geometry back.

github.com/iliaal/fastchart

fastjson 0.4.0: JSON Pointer, merge-patch, and a relaxed decode mode

fastjson 0.4.0 grew document-surgery functions, a tolerant decode mode for config files, and an 8.1 floor. The two RFC functions are the interesting part because they avoid the full decode-and-re-encode round trip.

fastjson_pointer_get() reads a single value out of a JSON document by RFC 6901 pointer, materializing only the subtree you asked for instead of the whole thing into PHP.

$email = fastjson_pointer_get($json, '/users/0/email');

fastjson_merge_patch() applies an RFC 7386 merge patch and returns the merged document, recursing into objects and treating a null member as a delete. Both keep fastjson's json_last_error-compatible error reporting, so a parse failure sets the error state or throws under JSON_THROW_ON_ERROR, matching the native functions.

The second addition is FASTJSON_DECODE_RELAXED, which decodes the JSONC subset that ext/json rejects: line and block comments, trailing commas, and a leading BOM. It is backed by yyjson's own read flags rather than a pre-pass scrubber, so well-formed JSON decodes identically with or without it. Useful for hand-edited config files where you want comments without giving up the speed.

$cfg = fastjson_decode($jsonc, true, 512, FASTJSON_DECODE_RELAXED);

0.4.0 also added fastjson_file_decode() and fastjson_file_encode(), which collapse the read-then-decode and encode-then-write patterns into one call that still goes through the PHP streams layer, so stream wrappers and open_basedir apply exactly as they do for file_get_contents().

github.com/iliaal/fastjson

phpser 0.2.0: a faster decoder and a closed key-smuggling gap

phpser 0.2.0 lowers its floor to PHP 8.2, makes object decode meaningfully faster, and fixes a correctness bug in the untrusted decode path that is worth understanding even if you never hit it.

The decoder now resolves dictionary strings against the engine's interned-string table, so interned hits skip the per-slot allocation and all the refcount traffic. Objects go a step further: declared properties install straight into their property slots via ce->properties_info instead of building a properties HashTable per object. On the DTO-batch shape that Laravel queue and cache payloads actually look like, decode came out about 22 to 25 percent faster, and the decoded objects no longer carry a materialized table they didn't need.

Shape	Decode before	Decode after	Delta
DTO batch (same-class)	baseline	property-slot install	~22-25% faster
Rowset	baseline	interned-string reuse	~9% faster

Measured against phpser 0.1.x on arm64, median of 12 runs.

The correctness fix: a crafted payload with a canonical numeric string array key, "5", now decodes to the integer key 5, matching native unserialize() and every array write PHP does. The untrusted path previously preserved it as a string key, a HashTable state no PHP code can actually produce. That let an attacker smuggle a value past isset() and array_key_exists() checks that assumed the key had already been coerced to an integer. The HMAC-signed path was never affected, because the encoder only ever emits integer keys for numeric strings, but the unsigned path is exactly the one you would point at untrusted storage, so it mattered.

github.com/iliaal/phpser

A native extension only earns its place by being installable, so this round put as much work into reach and safety as into raw speed.

I Generate Too Many UUIDs. So I Wrote a Faster One.

Ilia Alshanetsky — Sun, 07 Jun 2026 14:13:54 +0000

I generate a lot of UUIDs. Primary keys, cache keys, event IDs, request-trace IDs. Probably too many, if I'm honest about it. On a busy request path the same function gets called dozens of times before the response is even assembled, and across a fleet that adds up to a number of UUIDs per second I would rather not write down.

For years that cost was invisible to me, the way a single random_bytes() call is invisible until you make a few billion of them. Then it showed up in a profile, sitting higher than it had any right to, and I started paying attention to where the time actually went. It went to two places: pulling fresh entropy from the kernel once per UUID, and formatting 16 raw bytes into the 36-character canonical string. Both are cheap. Neither is free. Multiply by "too many" and you get a real slice of CPU spent doing nothing but minting identifiers.

So I wrote fast_uuid, a PHP extension that does UUID generation in pure C. This post is about why the two existing options each left a gap, what the extension does differently, and what it costs you.

The two options I already had, and where each one stopped

PHP developers generating UUIDs today reach for one of two things, and both are good at what they do.

The PECL uuid extension wraps libuuid from util-linux. It is fast at version 1 (time-based) UUIDs, because libuuid has a tuned generator for them. But it has three problems for my use case. Its version coverage is partial: v1 and v4 are reliable, v3 and v5 live behind separate uuid_generate_md5() / uuid_generate_sha1() functions, v6 and v7 only compile in if you built against a recent enough libuuid, and v8 is absent entirely. Its v4 path is slow, because it asks the kernel for fresh entropy on every call. And its API looks nothing like the ramsey/uuid code most projects are already written against, so adopting it means rewriting every call site.

There is also a licensing wrinkle worth stating precisely, because it is easy to get wrong. libuuid itself is BSD-3-Clause and permissive. The PECL uuid extension that binds it, however, is LGPL-2.1-or-later. If you only ever apt install the package that's no issue, but the moment you want to vendor the binding, ship it inside a permissively-licensed product, or relicense around it, the copyleft on the PHP binding is friction the BSD library underneath does not have.

The other option is ramsey/uuid, and it is excellent. MIT-licensed, every RFC version, ULID support, an API that has become the de facto standard in the Laravel and Symfony worlds. I have used it for years and have no complaints about its correctness or its ergonomics. The one thing it can't escape is that it's PHP. Its v4 generator calls random_bytes() once per UUID, and that syscall dominates a job that is otherwise a few dozen nanoseconds of work. Its v1 path is its slowest, because the clock-sequence and node bookkeeping all happen in PHP. And for UUIDv7, which I now reach for on time-ordered primary keys, getDateTime() hands you a DateTimeImmutable at millisecond resolution with no cheap integer-millisecond path to skip the object construction entirely.

So the gap was specific. One option is fast on a narrow set of versions but licensed awkwardly and API-incompatible. The other is broad and beautifully designed but pays a PHP-level cost on the hot path. Nobody covered speed and full RFC 9562 coverage and a familiar API at the same time. I wanted all three.

What "tackle both" actually meant

The design target was three things at once, none of them negotiable.

Full RFC 9562 coverage: versions 1, 2 (DCE Security), 3, 4, 5, 6, 7, 8, plus nil and max. Not "the popular ones." All of them, so the extension is never the reason you can't use a version.

An API a ramsey/uuid user already knows. The object API mirrors ramsey/uuid under the FastUuid namespace, so the cold-path ergonomics are familiar. For the hot path there is a procedural, zero-allocation set of functions (uuid_v4(), uuid_v7(), and friends) that return a zend_string directly with no object to allocate or free.

Pure C, no C++. No libstdc++ to link against, no external UUID library to track for version skew or licensing. The whole thing is BSD-3-Clause, including the entropy and formatting paths, so there is no copyleft binding sitting between you and a permissive license.

The rest of the post is the two optimizations that close the speed gap, the UUIDv7 work, the numbers, and the honest costs.

Why ramsey/uuid spends its time in random_bytes, and what to do instead

The short version: random_bytes() is a syscall, and a syscall per UUID is the bottleneck. fast_uuid makes one kernel entropy request and serves hundreds of UUIDs from it before going back.

Generating a v4 UUID is 16 random bytes with six bits overwritten for version and variant. The randomness is the entire job. In ramsey/uuid that randomness comes from random_bytes(16), which on Linux funnels into the getrandom() syscall. Crossing into the kernel and back costs far more than the handful of nanoseconds it takes to set the version bits, so at scale you're not paying for UUID generation, you're paying for syscalls.

fast_uuid keeps an 8 KB per-thread buffer and fills it with a single getrandom() call. At 16 bytes per v4 UUID that one syscall covers roughly 500 UUIDs before the buffer needs refilling. The entropy is exactly as fresh, it comes from the same kernel CSPRNG, you just amortize the crossing cost across the batch instead of paying it every call. That single change is most of the order-of-magnitude gap on v4.

For callers who want raw speed on identifiers that are not security-sensitive, there is also uuid_v4_fast(), which draws from a xoshiro256** PRNG instead of the kernel. That's a deliberately non-cryptographic generator. It's for ORM keys and trace IDs where unpredictability isn't a security property, and I'll say plainly in the next section why you must never reach for it when it is.

Turning 16 bytes into 32 hex characters without a loop

The other half of the cost is formatting. The answer-first version: converting the binary UUID to its canonical hex string is a per-byte lookup loop in most implementations, and a single SIMD table-lookup instruction can do 16 bytes at once.

The canonical string is the 16 bytes expanded to 32 hex characters with four dashes inserted. Done scalar, that is a loop with two nibble lookups per byte. fast_uuid does it with one vector instruction over the whole 16 bytes: pshufb on x86-64 (SSSE3), vqtbl1q_u8 on ARM64 (NEON), both of which are byte-shuffle table lookups that turn a vector of nibbles into a vector of ASCII hex digits in a single shot. The extension picks which to use at runtime from CPU feature detection, and falls back to a scalar lookup table on anything without those instruction sets. There are no build flags to set and no -march to remember; the extension chooses the right path when it loads.

The object itself is built for the same frugality. It is 16 inline bytes plus a lazily-cached canonical string, with no HashTable and no declared properties, so there is no per-object property storage to allocate and tear down.

UUIDv7 with sub-millisecond ordering, and a thank-you to Ben Ramsey

UUIDv7 is the version I care most about, because it gives you time-ordered, index-friendly primary keys without a separate sortable column. The answer-first claim: fast_uuid keeps v7 UUIDs in correct time order even when many are generated inside the same millisecond, and gives you an integer-millisecond path that skips DateTime entirely.

The v7 layout is a 48-bit Unix millisecond timestamp, then the version and variant bits, then rand_a (12 bits) and rand_b (62 bits). The problem with a plain implementation is that two UUIDs minted in the same millisecond have the same timestamp and random tails, so their sort order within that millisecond is arbitrary. RFC 9562 anticipates this in section 6.2. Its Method 3, "replace leftmost random bits with increased clock precision," puts a sub-millisecond clock fraction into the leftmost bits of rand_a. fast_uuid does exactly that, and adds a monotonic counter in rand_b, so same-millisecond v7s still sort in generation order. Your database index stays happy.

On top of the ordering work there is an integer-millisecond API: uuid_v7_at(int $ms), Uuid::uuid7(int $ms), and getTimestampMillis(). These let you stamp a UUID at a known time, or read its time back, as a plain integer, without constructing a DateTime object on either side. The DateTime accessors that do exist read and write ext/date's internal timelib_time structure directly rather than routing through call_user_function, which is roughly three times cheaper.

Conversations with Ben Ramsey sharpened some of these choices. He was generous with feedback while I was building this, and he shared where he's taking identifiers next with ramsey/identifier, a newer library spanning UUIDs, ULIDs, and Snowflake IDs that points at the direction he sees superseding ramsey/uuid over time. That nudged me toward future-proofing the API surface: alongside the get* method names every ramsey/uuid user knows, fast_uuid also ships to* aliases, so code written today reads the same whichever way the wider convention settles. Credit where it is due. ramsey/uuid set the bar I was building against, and Ben pointing at what comes after it shaped the parts of this extension meant to outlive the current convention.

The numbers

Throughput against ramsey/uuid 4.9.2 and the PECL uuid extension 1.3.0, on PHP 8.4.22 NTS, non-debug, no sanitizers, with the SSSE3 hex formatter active on x86-64. Each operation runs 300,000 iterations after a 20,000-iteration warmup, and the reported figure is the best of 40 runs. Units are million operations per second, higher is better.

Operation	fast_uuid (obj)	fast_uuid (proc)	ramsey/uuid	PECL uuid
v4 gen to string	12.6	19.5	1.10	0.47
v1 gen to string	12.3	16.5	0.29	8.22
v7 gen to string	12.1	19.8	0.66	n/a
parse to 16 bytes	10.4	16.2	3.18	5.28

Against ramsey/uuid that is roughly 11.5x to 17.7x on v4, 42x to 57x on v1, 18.3x to 30x on v7, and 3.3x to 5.1x on parsing. The v1 gap is the widest because v1 is ramsey/uuid's slowest path and close to fast_uuid's fastest. Note also that PECL is faster than ramsey/uuid on v1 (8.22 vs 0.29) and that this is the one row where PECL is strong, yet fast_uuid still clears it, while on v4 PECL drops to 0.47 because it asks the kernel for entropy every call.

One honest caveat that I keep in BENCHMARKS.md and will not drop here: the fast_uuid operations are fast enough (around 50 ns) that scheduler noise dominates a single run, so read the fast_uuid columns as order-of-magnitude rather than three-significant-figure, roughly plus or minus 10 percent run to run. The ramsey/uuid (around 900 ns) and PECL (around 2 microseconds) columns reproduce to within about 3 percent. If you cite these numbers, cite them with the comparison set and build: vs ramsey/uuid 4.9.2 and PECL uuid 1.3.0, PHP 8.4.22 NTS non-debug, best of 40 runs. ARM64 NEON numbers and the full timestamp-API table are in the repo.

For a byte-layout-heavy extension the more important number than throughput is correctness. It builds green on PHP 8.1 through 8.6, NTS and ZTS, with zero compiler warnings, and runs clean under AddressSanitizer and UndefinedBehaviorSanitizer across five build configurations.

What it costs you

No optimization is free, and hiding the costs would defeat the point of writing this honestly.

uuid_v4_fast() uses xoshiro256**, which is fast and statistically good but not cryptographically secure. Use it for keys and trace IDs where unpredictability is not a security requirement. Never use it for session tokens, password-reset nonces, or anything an attacker benefits from guessing. The kernel-backed uuid_v4() is right there for those.

The ramsey/uuid compatibility layer, FastUuid\Compat, is a PSR-4 companion package that makes migration largely a use swap. It is not on Packagist yet, so today you install it as a Composer path repository rather than a plain composer require. Adoption is a migration, not a binary swap.

If you supply a custom RandomGeneratorInterface, TimeGeneratorInterface, or NodeProviderInterface, generation intentionally routes off the C fast path, the same way ramsey/uuid lets you override its internals. Your generator wins, and you give up the speedup for those calls. That is the correct trade, but it is a trade.

And getDateTime() reads v7 timestamps back at millisecond precision, matching ramsey/uuid, even though the extension carries sub-millisecond data internally for ordering. The sub-ms fraction exists to keep same-millisecond UUIDs sorted, not to hand you back a nanosecond clock.

Getting it

The extension is BSD-3-Clause, builds on PHP 8.1 through 8.6, and is PIE-installable:

pie install iliaal/fast_uuid

Prebuilt binaries cover Windows x86/x64 (NTS and TS), Linux glibc x86_64 and arm64, and macOS arm64. Source, benchmarks, and the compatibility layer are at github.com/iliaal/fast_uuid.

UUID generation is the kind of cost you never notice until you're doing it a million times an hour, and then it's the kind you can't un-see. fast_uuid gives most of that cost back without asking you to relearn an API or drop a single RFC 9562 version, and it gets a little faster every release.

phpser: a fast, secure binary serializer for PHP cache workloads

Ilia Alshanetsky — Tue, 02 Jun 2026 18:53:39 +0000

I've reached for igbinary on nearly every PHP project I've shipped in the last decade. It's smaller and faster than PHP's native serialize(), it's stable, and it has been the obvious default for so long that reaching for it stopped being a decision.

So phpser started as curiosity, not a complaint. igbinary is good. Could a serializer built specifically for cache workloads do better?

I wanted two things from it. It should be fast on the shapes a cache actually holds, where a value is decoded far more often than it's encoded. And it should be safe to decode bytes from a store an attacker might reach, because unserialize() on untrusted input is one of PHP's oldest exploit primitives. igbinary gives you the speed; the safety you bolt on yourself. phpser builds in both.

On the shapes that matter for caches it encodes 10 to 70% faster than igbinary and decodes 12 to 75% faster, with packed numeric data also 65% smaller on the wire. Its signed mode refuses to decode any payload that wasn't produced with your key, so a poisoned cache entry never reaches the code that builds objects. The rest of this post is how it gets both.

Why a serializer built for caches?

Because igbinary optimizes for the general case, and a cache is not the general case, on two axes.

The first is the read/write asymmetry. A PHP cache pays decode cost on every single read. Encode happens once, when you write the value; decode happens every time anything reads it back. For a read-heavy cache that ratio is easily 100 to 1. igbinary, like most general serializers, balances the two sides. A cache serializer shouldn't.

The second is trust. The thing reading those bytes back is often reading from redis, memcached, a file, or a cookie, any of which an attacker may be able to write to. A general serializer treats decode as a pure data operation. A cache serializer has to treat it as a trust boundary.

igbinary is still the right default for general use. I went looking for the specific shapes where a cache-focused design could pull ahead, and there are three that show up everywhere in real PHP backends:

Packed numeric arrays. range(0, 999), ID lists, analytics buckets, sensor readings.
Deep-nested structures. Trees, recursive config, nested document structures.
Same-class object batches. Laravel queue payloads, cached Eloquent models, any array of a few hundred identical-shape DTOs.

Designing the format for the reader

The performance half of phpser borrows an instinct from Rust's rkyv. rkyv's pitch is that deserialization should be nearly free, because the writer already laid the bytes out the way the reader needs them. You don't parse an rkyv archive so much as point at it.

phpser isn't zero-copy, and I want to be precise about that before the comparison runs away. PHP values are refcounted zvals with owned hashtables; you can't hand PHP a pointer into a cache buffer and call it an array. phpser does a real decode pass and builds real zvals. It's not rkyv.

What transferred is the instinct, not the mechanism. rkyv made me stop thinking about the wire format as a neutral container and start thinking about it as a set of instructions to the reader. If the writer knows something that saves the reader work, the writer should record it, even when that makes encoding a little more complex. Once you adopt that lens, a set of concrete decisions falls out of it.

A string dictionary, and an intern that survives decode

The honest starting point: a front-loaded string dictionary isn't novel. igbinary already does this, it calls them compact_strings. Both serializers emit each distinct string once and reference it afterward, so the property name "created_at" repeated across a thousand cached rows costs one copy, not a thousand.

The dictionary isn't where the win is. The win is on the decode side, and it's the most direct application of the design-for-the-reader rule.

When phpser decodes a dictionary string the first time, it allocates a zend_string. Every later reference to that same dictionary index doesn't allocate; it bumps the refcount on the one already built. A thousand rows that all carry the key "user_id" produce exactly one string allocation and 999 refcount increments. PHP's own machinery is built for exactly this, interned strings are shared by refcount throughout the engine, so phpser isn't fighting the runtime, it's leaning on it.

Fast to encode, too

Designing for the reader could have meant a slow writer. It doesn't, because of two encoder choices, and the result is that phpser encodes faster than igbinary on every shape I test.

The first is the intern cache. phpser keeps an open-addressed zend_string*-to-slot hash, grown without eviction. Before hashing a string's bytes, it checks pointer identity: PHP interns string literals, so the "id" in row 1 and the "id" in row 900 are usually the same pointer and resolve with no byte work at all. Just as important, a unique value string, a name, an email, a SKU, takes a single-probe miss instead of a linear scan. The per-value dedup lookup stays off the critical path even on payloads full of strings that never repeat.

The second is objects. Encoding a PHP object the obvious way calls get_properties, which materializes a properties hashtable even for a plain object whose layout is fixed and known. For a batch of a few hundred DTOs that's hundreds of throwaway hashtables. phpser serializes a plain object straight from its declared property slots and skips the hashtable, the way native serialize() does. PHP 8.4 lazy objects fall back to get_properties, because their initializer has to run first.

Tagged scalar runs, and building the array in place

Two more decisions, on the decode side, are what make the packed-numeric numbers as large as they are.

The first is tagged scalar runs. igbinary encodes [1, 2, 3, ...] as a sequence of tagged values: a type tag and a varint, a thousand times over. phpser detects a uniform run and emits one PACKED_LONGS header plus the thousand integers as raw zigzag varints, no per-element tag. Decode becomes one tight loop with zero tag dispatch.

The second is building the hashtable in place. When the wire format says PACKED_LONGS of length N, the decoder knows the final size before it reads a single element. So it allocates the array once with zend_new_array(N) and writes the values directly into PHP 8's packed arPacked storage with ZVAL_* macros. That skips N calls to zend_hash_next_index_insert, and with them N hash computations, N capacity checks, and the incremental table growth that a naive decoder pays as it discovers the array's size one element at a time. The writer recorded the size so the reader could allocate once and fill, which is the rkyv instinct applied as far as a non-zero-copy format can take it.

The benchmarks

Here is the full shape-by-shape comparison, run on my machine, against igbinary. The bench harness (bench.php in the repo) round-trips every shape for correctness first, then times encode and decode separately, because decode is the number that matters for a cache.

Methodology: phpser 0.1.2, PHP 8.4.22-dev NTS, release build (not a debug or ASan build, which would inflate everything 2 to 5x), igbinary 3.2.17RC1, Intel Core i9-13950HX. 1,000 iterations per shape, median of 9 runs after a discarded warm-up.

Shape	Size: igbinary → phpser	Encode: igbinary → phpser	Decode: igbinary → phpser
packed_1k	5,495 → 1,941 B (-65%)	4.6 → 1.4 µs (-70%)	7.3 → 1.8 µs (-75%)
packed_10k	59,495 → 21,749 B (-63%)	46.4 → 13.7 µs (-70%)	74.0 → 18.9 µs (-74%)
deep_50	419 → 424 B (+1%)	1.3 → 0.62 µs (-54%)	1.8 → 1.6 µs (-15%)
dto_100	7,083 → 6,362 B (-10%)	15.5 → 13.9 µs (-10%)	26.9 → 23.5 µs (-13%)
dto_1000	73,372 → 64,863 B (-12%)	194 → 165 µs (-15%)	275 → 227 µs (-18%)
rowset_100	4,570 → 4,771 B (+4%)	10.0 → 7.3 µs (-27%)	10.7 → 10.8 µs (+1%)
rowset_1000	47,459 → 47,972 B (+1%)	157 → 71 µs (-55%)	104 → 107 µs (+4%)
dto_mixed	21,644 → 17,927 B (-17%)	58.8 → 39.8 µs (-32%)	112 → 81 µs (-28%)

The packed rows are the ones that jump out: roughly two-thirds smaller and three-quarters faster to decode, on a real shape, not a synthetic micro-case. packed_1k is range(0, 999), which is what an ID list or an analytics bucket looks like.

The DTO rows are the relatable ones. dto_1000 is a thousand small typed objects of one class, the shape a Laravel queue batch or a page of cached models actually has. 12% smaller, 18% faster to decode, 15% faster to encode, from the dictionary dedup on property names and a class-entry lookup cache that amortizes zend_lookup_class_ex across the batch. Encode is faster than igbinary on every row; the largest margins are on the object-heavy dto_mixed (32% faster, 17% smaller) and the mixed rowset_1000 (55% faster).

Where it gives a little back

The one row where phpser loses is the mixed associative rowset. rowset_1000 decodes about 4% slower than igbinary, and the rowset payloads run 1 to 4% larger. That's the front-loaded dictionary showing its one downside: the decoder walks the dictionary header before it touches values, and on a heterogeneous rowset with few repeated strings that header walk doesn't buy back its cost. It's a small tax, and it's on the exact axis I chose to de-prioritize, but it's real and measured, so there it is.

The structural limit is the same decision seen from another angle: phpser isn't streamable. The dictionary lives at the head of the payload and values reference it by index, so you can't decode the stream incrementally as it arrives. The front-loaded dictionary is what makes the other decodes fast and what makes streaming impossible. You don't get to keep both. If you need a streaming parser, this is the wrong format.

I also cross-checked the whole suite on arm64 to make sure none of this was an x86 quirk. Same direction on every shape, with narrower encode margins on the object cases. The decode wins and the single rowset_1000 decode tax both reproduce.

Signed payloads: safe to decode from an untrusted cache

The performance half is only one reason a cache serializer is its own problem. The other is that decoding attacker-controlled bytes is dangerous. Native unserialize() on untrusted input lets a crafted payload instantiate any allowed class and drive its __wakeup, __destruct, or other magic methods into a state the code never anticipated. That's the mechanism behind object-injection and gadget-chain attacks, and a cache is the soft spot: a redis instance, a memcached pool, a file cache, or a cookie is exactly the kind of store an attacker reaches in a real incident, and whatever sits there gets decoded on the next read.

phpser's answer is a signed mode built on HMAC-SHA256. You serialize with a secret key, and you refuse to decode anything that wasn't signed with that same key. Verification is constant-time and runs before any decoding work, so a tampered or foreign-keyed payload never reaches the part of the decoder that builds values or constructs objects.

$key = random_bytes(32);            // generate once, keep it in app config or a secrets manager

// on write
$blob = phpser_serialize_signed($cacheValue, $key);
$redis->set('user:42', $blob);

// on read
$blob  = $redis->get('user:42');
$value = phpser_unserialize_signed($blob, $key);

if ($value === null) {
    // tampered, truncated, or signed with a different key.
    // nothing was decoded; treat it as a cache miss and rebuild.
    $value = rebuild_user(42);
}

The contract is deliberately blunt. phpser_unserialize_signed() returns null on any signature failure rather than throwing, so a poisoned cache entry degrades to a miss instead of an exception in a hot read path. The decode only proceeds once the MAC matches. This is authentication, not encryption: the bytes are still readable, but they can't be forged without the key, and that's the property that keeps a crafted object graph out of your decoder.

Signed mode also refuses an empty key. An empty key would reduce HMAC-SHA256 to a fixed, keyless tag anyone can recompute, so a caller writing phpser_serialize_signed($v, getenv('SECRET') ?: '') with the variable unset would be shipping forgeable payloads without knowing it. Both signed entry points throw on an empty key before doing any work, so that misconfiguration fails loudly instead of silently defeating the signature.

If you genuinely can't sign, because you're decoding bytes from a source you don't control and can't key, the second line of defense is allowed_classes, with the same shape as PHP's native unserialize():

// reject every class: unknown objects decode as __PHP_Incomplete_Class, never instantiated
$value = phpser_unserialize($blob, ['allowed_classes' => false]);

// or allowlist only the classes you actually expect to read back
$value = phpser_unserialize($blob, ['allowed_classes' => [UserDto::class, OrderDto::class]]);

The same option works on phpser_unserialize_signed() too, so you can combine a valid signature with a class allowlist for defense in depth. Underneath both paths, the decoder is hardened on its own: a recursion depth cap of 512 bounds stack use against deliberately deep payloads (decode returns null, encode throws), and crafted payloads naming a missing enum case or a non-serializable class like Closure are rejected rather than crashing, matching what PHP's own unserialize() refuses.

What I took away

igbinary is still the serializer I'd reach for on a general-purpose workload, and I'll keep using it. It's mature, it's everywhere, and on a mixed rowset it's still a hair ahead on decode.

For a read-heavy cache, phpser gives me two things at once. It's faster on the shapes caches actually hold, encode and decode both, because the wire format is designed around the reader rather than balanced between reader and writer. And signed mode means I can decode from redis without treating every read as a potential injection. Speed and trust are the two things a cache serializer has to get right, and they're the two things a general serializer leaves half-finished. Building both in was the point.

pie install iliaal/phpser

Source, wire-format spec, and the bench harness: github.com/iliaal/phpser