DEV Community: Ilia Alshanetsky

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

Fastchart 1.X, why I rewrote it after 0.2 release

Ilia Alshanetsky — Fri, 22 May 2026 12:16:57 +0000

Couple of weeks ago I shipped fastchart 0.2.0 and wrote it up here. One extension, 19 chart types, server-side rendering through ext/gd.

The idea was right, but execution not quite there.

After the launch I spent a few days actually looking at the output side by side with what plutovg can do on the same primitives. The libgd-rendered charts were fine for what libgd is, which is a 1990s 2D rasterizer with no subpixel-precise anti-aliasing. Diagonal lines were jaggy. Glyph edges grainy at small sizes. The output read as "a chart drawn by ext/gd in 2026" instead of "a chart." A couple of Reddit threads (r/PHP and r/laravel) pointed at the same thing without me having to ask.

So I rewrote it. fastchart 1.1.1 is the current stable of that rewrite, following a number of stabilization tweaks and refinements, the end result being SVG promoted to the canonical render format, and the chart-family count up from 19 to 26.

What was wrong with the libgd output

libgd's anti-aliasing is gdAntiAliased plus the alpha channel. It works for solid-fill regions. It falls apart on the boundary between two filled regions of different colors, on glyph rendering at body-text sizes, and on rotated text where the rotation axis isn't a 45° multiple.

Specific cases I kept hitting:

Diagonal series lines in a LineChart showed visible stair-stepping at 1px stroke width. libgd's gdImageLine with gdAntiAliased blends against the canvas background, not the local color, so a red line crossing a blue series region looked correct on the white margin and wrong inside the plot area.
45° rotated X-axis labels (the default when categorical labels are long) had a noticeable diagonal moiré along the baseline. Different from the line issue: this came from libgd's FreeType bridge, which renders each glyph straight then resamples the resulting bitmap. The double rasterization loses sharpness.
StockChart hollow candles drew the body outline with the same primitive as the wick, so the body edges and the wick had the same line weight even when they shouldn't. The fix would have been a separate primitive; libgd has no concept of stroke vs fill weight at the polyline level.

None of these are libgd bugs. They are libgd doing exactly what libgd has always done. They are also not things I can fix in a wrapper.

Why SVG won

The shortest path from "I want sharper output" to "the output is sharper" is to stop rasterizing in the render path at all. SVG is text. The render path appends strings into a smart_str. The reader (a browser, an inkscape, a plutovg) does the rasterization at the resolution and pixel density it wants.

That solves the visual-quality complaint by default. It also gives back DPI-independent output: a chart embedded in a PDF or rendered at retina density on a Mac no longer needs setDpi(192) to look right.

Not everyone wants or needs SVG, so the architecture needs a path for traditional image formats too (PNG / JPG):

Every chart family builds an SVG document.
renderSvg() returns the document bytes.
renderPng() / renderJpeg() / renderWebp() flatten the SVG's <text> elements to glyph outline paths via FreeType, run the result through plutovg + plutosvg (vendored, both MIT-licensed), and encode the rasterized RGBA buffer with libpng / libjpeg-turbo / libwebp.

Same chart object, four render methods, four outputs. No second code path for rasters; the raster encoders sit downstream of the same vector builder.

The cost is that fastchart now links against four codec libs instead of one. The benefit is libgd is gone, both as a build dependency (no libgd-dev apt package required) and as a runtime requirement (the chart classes no longer touch GdImage at all).

The 1.x arc

1.0.0: the rewrite

The architectural pivot. SVG canonical, libgd dropped, plutovg + plutosvg vendored. Seven new chart families lifted the family count from 19 to 26: BulletChart, ParetoChart, CalendarHeatmap, SunburstChart, SankeyChart, MarimekkoChart, VectorChart. All seven were sitting in the same private-extensions queue as the 0.2.0 set; pulling them into the public repo was easier once the architecture was settled.

Breaking changes from 0.2.0: no more GIF support, and no more GdImage canvas input/output.

1.0.(1-2): build portability

1.0.1 added prebuilt binaries via PIE for Windows (PHP 8.3 / 8.4 / 8.5, NTS + TS, x64 + x86) and Linux x86_64 / arm64 + macOS arm64 (PHP 8.4 / 8.5 NTS). 1.0.2 fixed a libjpeg soname mismatch that broke the Linux prebuilts on Debian-based PHP, including every official php:X.Y-cli Docker image. The fix statically links libjpeg-turbo from a configure-time source build, with -Wl,--exclude-libs=ALL so the static symbols stay local to fastchart.so and don't collide with the system ext/gd in the same process.

1.1.0: features on the new pipeline

AreaChart::setBandMode(bool) for confidence-interval and min-max envelope fills. PolarChart::setInterpolation(INTERP_SMOOTH) for Catmull-Rom-subdivided polar curves. PolarChart::addVectors() to overlay arrow vectors in (angle, radius) data space. Funnel::setStyle(STYLE_CONE) for a pyramid with front-facing ellipse-arc edges. BubbleChart::setYAxisScale(SCALE_LOG). And Chart::setImageMap() + getImageMap() for HTML image-map hot-spots on BarChart, PieChart, and ScatterChart, with allowlisted URL schemes (http / https / mailto / / / #) and HTML-escaped tooltip text.

1.1.1: hardening

Shipped today. No new APIs, no breaking changes. Fourteen fixes to improve code quality. A non-exhaustive sample:

PolarChart::addVectors() rejects NaN / Inf at the boundary now, matching every other polar setter. The float-to-int cast it was feeding is UB per C11 §6.3.1.4p1.
MarimekkoChart::setColumns() running-sum overflow. Each individual segment value was isfinite-guarded, but the per-column sum and cross-column total could overflow to +Inf from two segments at 1e308 each. Columns whose running sum is non-finite are now silently dropped.
StockChart STYLE_VECTOR climax-deque ring-buffer overflow. After 11 strictly-decreasing pushes the deque tail wrapped to the head and every subsequent bar got misclassified as a climax. The stale-front drop now runs before the push.
JPEG encoder local pointers carry volatile across setjmp(). Per C99 §7.13.2.1 a register-spilled local that libjpeg's longjmp clobbers is UB; the cleanup branch could leak or double-free.
fc_ft_measure() was a 1 / 2 / 3-byte UTF-8 decoder. Non-BMP codepoints (emoji, CJK extensions, mathematical alphanumeric symbols) contributed 0 to the measured width, so chart layout reservations came up systematically narrow on labels containing emoji. 4-byte branch added.
Time-axis arithmetic on setOhlcv timestamps near LLONG_MIN..LLONG_MAX overflowed signed zend_long in four call sites. Promoted to double arithmetic; out-of-range double-to-zend_long casts clamped.
Vendor refresh: plutosvg 0.0.7 to 0.0.8, plutovg 1.3.2 to 1.3.3. Most of fastchart's local patches (UTF-8 BOM handling, FT include, sprintf to snprintf, bilinear tile sampling) are now upstream. Preserved fastchart-only: the stb_image PNG palette zero-init and the STBI_ONLY_PNG / STBI_ONLY_JPEG cut that drops ~70% of the stb image-loader binary.

Full list in CHANGELOG.md.

Outside contributions

Along the way the 1.x cycle caught the attention of Remi Collet, who runs the rpms.remirepo.net PHP RPM repository (the standard PHP RPM source for RHEL / Fedora / CentOS). Three merged PRs landed between 1.1.0 and 1.1.1: a test-path correction so the suite finds the build directory regardless of out-of-tree builds, a fix for an undefined $ext_builddir that broke the Fedora PHP build glue, and an additional Fedora-family font-path probe (/usr/share/fonts/lato/, /usr/share/fonts/TTF/) for MINIT's default-font detection. The cumulative effect is that fastchart now builds and runs cleanly under Remi's RPM packaging.

Performance: what each format actually costs

Median in-memory render time at 1920×1080 on a single core, Intel i9-13950HX, PHP 8.4 debug build, default font and DPI. SVG is the canonical output; PNG / WebP / JPG add their rasterize + encode cost on top of the SVG build.

Chart	SVG ms	PNG ms	WebP ms	JPG ms
AreaChart	5.7	71.7	54.4	34.5
BarChart	11.0	75.8	57.0	38.8
BoxPlot	4.4	65.0	47.5	31.6
BubbleChart	2.6	90.9	62.7	38.6
GaugeChart	1.2	69.4	49.7	29.1
LineChart	5.4	74.2	55.5	34.3
PieChart	2.8	71.6	51.9	33.0
StockChart	8.4	80.8	63.3	41.0

SVG sits between 1.2 ms and 11 ms across all 19 measured types. There is no rasterizer in that path; the backend appends strings into a smart_str and returns the bytes. The raster encoders split into three bands: JPG fastest at 25 to 41 ms (libjpeg-turbo with 4:2:0 subsampling), WebP middle at 41 to 63 ms (libwebp with WEBP_PRESET_DRAWING + method=2 + multi-thread, roughly 2× faster than the simple API the rewrite started with), PNG slowest at 62 to 91 ms (libpng's deflate dominates). All four formats stay under 95 ms at 1080p on one thread.

Full table for all 19 measured chart types in the README perf section. Reproduce with php -d extension=./modules/fastchart.so docs/bench/bench.php.

Composing without a shared canvas

The 0.2.0 differentiator was draw(GdImage $canvas): hand fastchart a gd canvas you owned, it drew into it, you composited multiple charts on one image. That API is gone in 1.x because v1.x owns its pixel buffer.

The replacement is drawSvgFragment() plus the static svgToPng / svgToJpeg / svgToWebp rasterizers:

$line = (new FastChart\LineChart(800, 600))
    ->setTitle('Daily active users')
    ->setSeries([['data' => $values]]);

$bar = (new FastChart\BarChart(800, 600))
    ->setTitle('Quarterly revenue')
    ->setSeries([['data' => $bars]]);

// Stitch two fragments into one outer SVG document.
$outer = <<<SVG
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="1600" height="600" viewBox="0 0 1600 600">
  <g transform="translate(0,0)">{$line->drawSvgFragment()}</g>
  <g transform="translate(800,0)">{$bar->drawSvgFragment()}</g>
</svg>
SVG;

// Take the stitched SVG either as bytes or rasterized in one call.
file_put_contents('/tmp/dashboard.svg', $outer);
file_put_contents('/tmp/dashboard.png', FastChart\Chart::svgToPng($outer));

Same dashboard story as the 0.2.0 example, no shared canvas. The rasterizer sees the full composed document and antialiases across fragment boundaries cleanly.

On Linux with a standard fonts package installed (Ubuntu's fonts-lato, Debian's fonts-dejavu, etc.) fastchart's MINIT auto-probes a default. On macOS or in minimal containers, add ->setFontPath('/path/to/font.ttf') on each chart so labels render.

The SVG-canonical pipeline also gave a freebie: svgToPng / svgToJpeg / svgToWebp rasterize any caller-supplied SVG bytes through the same plutovg + encoder path, not just fastchart's own output. If you need to convert an arbitrary SVG to PNG / JPG / WebP from PHP without shelling out to ImageMagick, rsvg-convert, or Inkscape, that's now in-process. The caveat is text: plutosvg has no text engine, so <text> elements in caller-supplied SVG render blank. Either pre-flatten to <path> (Inkscape's "Object to Path" works) or accept the limitation. Hard caps apply: 16 MB input, output dimensions capped at 4096 px and 16 Mpx, embedded data:image/ URIs rejected (plutosvg's loader bypasses the dim cap on those), <use> elements rejected (the cycle detector doesn't count fan-out, so nested <g><use/>×10 can hit billion-laughs expansion). Contract at docs/specs/svg-to-raster.md.

Try it

Full SVG + PNG + JPG + WebP gallery for every chart family at iliaal.github.io/fastchart/v1-gallery.html. Source PHP shown above each row.

pie install iliaal/fastchart

Repo: github.com/iliaal/fastchart. BSD-3, PHP 8.3+, NTS or ZTS.

What 0.2.0 got right

The 0.2.0 framing held: PHP doesn't need a Node sidecar for charts. The breadth held: 19 chart types covering Cartesian, financial, non-Cartesian, and specialised shapes is roughly the surface most dashboards need. The fluent OO API held. What didn't hold was libgd underneath it. libgd is fine for what libgd is; it isn't a 2026 chart rasterizer. A few releases later, fastchart isn't built on top of libgd anymore, and the output reads accordingly.

fastjson 0.3.0: A Faster Drop-In ext/json for PHP, Backed by yyjson

Ilia Alshanetsky — Wed, 20 May 2026 11:35:45 +0000

// Before
$payload = json_encode($response);
$data    = json_decode($input, true);
$ok      = json_validate($input);

// After
$payload = fastjson_encode($response);
$data    = fastjson_decode($input, true);
$ok      = fastjson_validate($input);

That's the migration. Search-and-replace json_* for fastjson_*. JSON flags, error constants, and last-error semantics carry across byte-for-byte. The two extensions sit next to each other in the same process; adoption is per call site, not per repo.

On the simdjson_php canonical 14.8 MB corpus, that swap buys 6.06× encode throughput, 2.66× decode, and 5.10× validate against ext/json on the same PHP 8.6.0-dev build. The repo is at github.com/iliaal/fastjson. 0.3.0 shipped yesterday.

Why drop in faster JSON for PHP

ext/json is fine. It's correct, well-maintained, and tracks the spec. On low-traffic endpoints it isn't on anyone's profiler. The cost shows up at scale: any application that calls json_encode and json_decode on every request path eventually finds JSON serialization sitting at the top of a flame graph. API gateways feel it first, then log processors and microservice fan-out paths.

Before fastjson the practical options were two:

Stay on ext/json. Eat the CPU cost.
Reach for simdjson_php. It's fast but decode-only and not API-compatible; every call site has to be rewritten around its result shape.

fastjson is option three. It's a native PHP extension that wraps yyjson 0.12.0 (MIT, ~6K LOC of focused C) behind a namespaced API that mirrors ext/json's contract. PHP 8.3 minimum; 8.4 and 8.5 supported; coexists with ext/json.

What "drop-in" actually means here

The risk with any "drop-in" claim is that it covers 90% of cases and silently changes behavior on the 10% that matter. So this section is what fastjson does and what it doesn't:

Function signatures track ext/json. fastjson_encode($value, int $flags = 0, int $depth = 512). Same positional shape. Same defaults. Same return values on success, false on failure.
JSON_* flags match byte-for-byte. JSON_UNESCAPED_SLASHES, JSON_UNESCAPED_UNICODE, JSON_PRETTY_PRINT, the JSON_HEX_* family, JSON_THROW_ON_ERROR, JSON_INVALID_UTF8_IGNORE, JSON_INVALID_UTF8_SUBSTITUTE. The integer constants are intentionally identical so user code can pass the same flag value into either function.
JSON_ERROR_* codes match byte-for-byte, messages don't. fastjson_last_error() returns the same JSON_ERROR_* int as json_last_error() for the same failure class, so code branching on error codes works without modification. fastjson_last_error_msg() returns yyjson's parser message (e.g., "unexpected character"), not ext/json's. Application code that pattern-matches on the message string needs updating; code that branches on the code does not.
Coexistence, not replacement. Both extensions load. Migrate the call sites where JSON is on the hot path; leave the rest on ext/json.
53 phpt tests rewritten from php-src/ext/json/tests/*.phpt run alongside fastjson's own suite. The rest of the upstream suite is categorized in tests/upstream-json/.skiplist with the reason each test was deferred (most are tests of ext/json internals that don't translate, a few hit known divergences).
Documented divergences. Large/scientific doubles emit 100000000000000000.0 where ext/json emits 1.0e+17 in some ranges. U+2028 / U+2029 line separators emit as ordinary code points; ext/json always escapes them for JSONP safety. Both divergences are in the skiplist with rationale.

The numbers

Full simdjson_php canonical corpus: 14.8 MB across 15 files, the same set the simdjson PHP binding has been benchmarked against for years. Hardware: i9-13950HX. PHP 8.6.0-dev, release build (-O2). fastjson built -O2 against the same PHP. yyjson 0.12.0 with three local patches. Numbers in throughput, MB/sec:

Operation	fastjson	ext/json	Speedup
Decode (stdClass)	602 MB/s	227 MB/s	2.66×
Decode (assoc array)	628 MB/s	237 MB/s	2.65×
Encode	1,092 MB/s	180 MB/s	6.06×
Validate	1,352 MB/s	265 MB/s	5.10×

Visual side-by-side, including ext/json with Nora Dossche's open SIMD encode work (php-src#17734) and simdjson_php on the same PHP 8.6.0-dev build, lives at https://iliaal.github.io/fastjson/baseline.html. Reproduce locally with bench/run.php against any PHP install.

The encode speedup is the largest gap because the PHP-native encoder has the most room to give back. ndossche's php-src#17734 patch closes a meaningful chunk of that gap inside ext/json itself using SIMD on string encoding. fastjson and that PR attack the same problem from different angles, and an application can benefit from both once #17734 lands upstream (fastjson re-baselines automatically; the visual page already shows both).

How the encoder gets to 6×

The encoder is one-stage. A zval walks straight into a smart_str buffer via yyjson's writer primitives. There's no intermediate DOM, no two-pass build-then-serialize, no temporary string allocations for the common-case scalars. Each PHP value type maps to one or two yyjson calls; arrays and objects walk recursively into the same path.

A few less-obvious pieces:

Custom allocator wired through Zend. yyjson's allocator hooks route every alloc/realloc/free through PHP's emalloc family. JSON workloads count against memory_limit and against per-request memory accounting; oversized inputs bail out the same way any other PHP allocation does.
Direct smart_str integration. No RETURN_STRING(estrdup(buf)) after a separate allocation. The yyjson writer writes into the smart_str.s backing store, which becomes the return zend_string directly. One allocation per encode call in the common case.
HEX_* flag scan-first. The flags JSON_HEX_TAG/HEX_AMP/HEX_APOS/HEX_QUOT rewrite specific characters into hex escapes. fastjson scans the string once for any candidate character; if none are present, the rewrite path is skipped entirely and the string is encoded directly. Defensive callers that pass HEX_* flags as a precaution on payloads that don't actually contain the substituted characters don't pay the rewrite cost.
Integer-valued-double shortcut. When a double round-trips losslessly through int64, fastjson emits it as an integer without going through php_gcvt or yyjson's REAL writer. A cheap range check fires before floor(), so number-heavy arrays of non-integer doubles don't pay libm per element.

The decode path's gain has different sources: yyjson itself, which parses with less branching and tighter memory locality than ext/json's parser, and a local yyjson patch (YYJSON_READ_VALIDATE_ONLY) that turns the read path into a fast validate-only mode without materializing values.

The memory tradeoff

Worth surfacing before anyone hits it in production. Decode and validate hold the yyjson document object in memory alongside the PHP-side result, because yyjson's value graph is built first, then traversed to produce zvals. Peak heap on decode is roughly 1.7× what ext/json peaks at on the same input. Encode is one-stage and peaks at ~1.06× of ext/json.

Validate is the loudest: peak heap is ~101× ext/json's streaming validator (which sits at a constant ~80 bytes since it doesn't materialize anything). The headline number sounds extreme, but the absolute footprint is bounded by yyjson's read path, and it's already 2.7× lower than yyjson's stock read path thanks to a vendored validate-only patch (YYJSON_READ_VALIDATE_ONLY) that skips the value-graph build.

For most callers, the speedup wins. If the application is validate-heavy on giant inputs under tight memory_limit, the memory profile is a real consideration. The right move there is to leave validate-on-huge-inputs on ext/json and migrate the encode and decode paths. That's exactly what coexistence buys.

Compat harness

53 rewritten phpt tests from php-src/ext/json/tests/*.phpt run alongside fastjson's native suite. They cover the common decode/encode/validate paths, the flag combinations, and the documented error conditions.

The two remaining intentional divergences:

Large/scientific doubles. Outside the integer-valued-double shortcut range, fastjson emits yyjson's real-number format. ext/json uses php_gcvt and switches to scientific notation earlier. The disagreement window narrowed in 0.3.0; what's left is the genuinely-fractional case where yyjson and php_gcvt produce different decimal representations of the same IEEE 754 double.
U+2028 / U+2029 line separators. ext/json always escapes these for JSONP safety. yyjson treats them as ordinary code points. fastjson follows yyjson's behavior. If JSONP is in the deployment path, set JSON_UNESCAPED_UNICODE off in ext/json and stay on ext/json for that endpoint, or wrap fastjson output through a JSONP-safe post-step.

Upstream collaboration with yyjson

fastjson vendors yyjson 0.12.0 with three local patches. Full details are in vendor/yyjson/PATCHES.md; the short version of each, and what happened when each was proposed upstream:

Lowercase hex digits in \uXXXX escape table. yyjson emits uppercase; ext/json emits lowercase. RFC 8259 §7 allows either, but byte-parity with ext/json is the project's compat goal. Proposed as yyjson#264 (YYJSON_WRITE_LOWERCASE_HEX flag) and accepted upstream on 2026-05-11. fastjson will drop this patch once the vendored sources advance past yyjson 0.12.0.
YYJSON_READ_VALIDATE_ONLY, no-tree validate mode. Forks yyjson's parser entry point to skip the value-graph build entirely; peak memory drops 2.7× on the validate corpus. Not yet proposed upstream; the API surface needs a round of review before it's ready to submit.
Public yyjson_write_string_to_buf() wrapper. Exposes yyjson's internal direct-write primitive so fastjson's one-stage encoder can compose at the buffer level. Proposed as yyjson#266 and closed upstream; the maintainer preferred to keep that surface private. The wrapper stays vendored locally; fastjson lives with it indefinitely.

Install

pie install iliaal/fastjson

Or build from source:

phpize
./configure
make -j
make test
sudo make install

PHP 8.3 minimum. No external library dependencies; yyjson is vendored in src/yyjson/.

The four-character migration

fastjson stays useful as long as yyjson's design choices (one-stage encoder, validate-only fast path, allocator hooks) beat what fits into ext/json's compatibility envelope. For the call sites where JSON serialization shows up on a flame graph, the migration is four characters; the rest of the codebase doesn't have to care.

Repo: https://github.com/iliaal/fastjson. Benchmark methodology and reproduction: bench/run.php. Visual baseline: https://iliaal.github.io/fastjson/baseline.html.

fastchart 0.2.0: Native PHP Charts, Barcodes, and QR Codes in One Extension

Ilia Alshanetsky — Tue, 12 May 2026 13:50:03 +0000

(new FastChart\StockChart())
    ->setSize(1200, 600)
    ->setTitle('AAPL last 90 days')
    ->setTheme(FastChart\Chart::THEME_DARK)
    ->setOhlcv($ohlcvRows)
    ->setMovingAverages([20, 50, 200])
    ->setVolumePane(true)
    ->setCandleStyle(FastChart\Chart::STYLE_HOLLOW)
    ->renderToFile('/tmp/aapl.png');

That's a server-side OHLCV candlestick chart with three moving averages, a volume pane, and a hollow candle style. Roughly 68 ms on a single core at 1920×1080. No microservice, no Node sidecar, no JavaScript runtime. PHP, gd, fastchart.

fastchart 0.2.0 shipped two days ago. 19 chart types behind a fluent OO API, plus a Symbol family (Code 128 barcodes and QR codes) that landed in this release. The repo is at github.com/iliaal/fastchart.

Why charts in PHP again

Twenty years ago, Rasmus and I shipped the initial release of PECL/GDChart in January 2006. It wrapped Bruce Verderaime's gdchart C library from users.fred.net/brv/chart/. The PECL page is still up at https://pecl.php.net/package/GDChart.

Both projects died. Verderaime's gdchart library hasn't moved since the mid-2000s; the homepage at users.fred.net/brv/chart/ has been a tombstone for almost as long. The PECL extension followed. One release, then nothing.

The PHP charting ecosystem since then has been thin. JpGraph kept moving but active development went to the commercial fork; the OSS branch is calcifying. pChart is unmaintained. Many PHP teams that need server-side charts in 2026 either reach for a Node or Python microservice (Chart.js via Puppeteer, matplotlib via subprocess) or accept that "server-side rendering" means "render in the browser and screenshot it." Neither is good.

Between PECL/GDChart and now, I've kept needing charts and graphs in PHP. Mostly charts, occasionally barcodes and QR codes. Each new project I'd reach for the easy options first: command-line tools wrapped through shell_exec, pure-PHP libraries when they were fast enough, more recently chart.js renders shipped through a Puppeteer or headless-Chrome wrapper. Those work until they don't. When scale showed up the wrapper started dominating request latency, and I'd write a little PHP extension that handled the specific case causing pain.

Roughly six of those extensions accumulated over the years. Each did one thing. One generated QR codes for serial numbers on physical labels. One drew two chart types for an internal reporting dashboard. One was just OHLC candlesticks with moving averages. None of them shipped. They lived in private repos, solved the immediate problem, and never got cleaned up enough to release.

fastchart is the attempt to close that gap publicly. One extension, the breadth of shapes I've kept needing, a fluent OO API, BSD-licensed. StockChart got the deepest treatment in this release (seven candle styles, the full indicator stack) because the most recent of the six private extensions was the trading-chart one and it carried over almost verbatim. The other eighteen chart types and the Symbol family came from cleaning up and merging the rest.

What's in 0.2.0

Nineteen chart classes plus a two-class Symbol family for barcodes and QR codes. Five output formats. Two render paths. The full surface is 105 public methods covered by 97 tests. PHP 8.3+ minimum, NTS or ZTS.

The chart classes split into four shapes:

Cartesian. Line, Area, Bar (vertical, horizontal, stacked, grouped, floating, layered), Scatter, Bubble.
Financial. A deep StockChart class: seven candle styles (CANDLE, BAR, DIAMOND, I_CAP, HOLLOW, VOLUME, VECTOR), SMA/EMA/WMA overlays, a volume pane, and indicator panes (RSI, MACD, Bollinger Bands, Parabolic SAR, Stochastic, OBV).
Non-Cartesian. Radar, Polar, Surface, Contour.
Specialised. Pie (with donut hole and leader lines), Gauge, LinearMeter, Gantt (with dependencies and milestones), BoxPlot, Treemap, Funnel, Waterfall, Heatmap.

The Symbol family added in 0.2.0:

Code 128. ISO/IEC 15417. Auto-switches between A/B/C subsets to minimize encoded length. Mod-103 checksum appended automatically. Optional human-readable payload rendered below the bars.
QR Code. ISO/IEC 18004. Four error-correction levels (ECC_L/M/Q/H), versions 1 through 40. Encoder is the vendored nayuki/QR-Code-generator C library under MIT.

Output formats are the standard gd set plus the modern ones: PNG, JPEG, WebP, AVIF, GIF.

Why barcodes and QR codes in a chart library

Because they all render to a gd canvas, they all serve the same use case (server-side image generation in PHP), and they share the same painful problem: the existing PHP-native options are mostly dead or third-party packages with their own dependency stacks.

The unifying thread is gd, not "chart." If you're rendering a dashboard tile, a sales report PDF, an invoice with a scannable serial number, or a shipping label with a barcode, you're producing an image on the server. PHP has had ext/gd since 4.0.0. fastchart treats ext/gd as the substrate and adds higher-level shapes on top. The Symbol classes don't claim to be charts; they live in their own family parallel to Chart, with shared base setters and the same render-format set.

The public options before fastchart were mostly pure-PHP libraries shipping their own glyph tables and rasterizers, or wrappers around command-line tools like qrencode. Both work. Both add a dependency surface that a pie install doesn't cover. fastchart pulls QR and Code 128 into the same .so as the charts. One install, one dependency (gd), one fluent API.

The compose path

Charts let you hand fastchart a \GdImage canvas you own. It draws into your canvas and returns the same canvas back. Symbols don't accept a caller-owned canvas (a barcode's quiet zone makes compositing inside an existing image ambiguous); they render fresh and you imagecreatefromstring() to composite afterwards.

The composability is the differentiator from JpGraph, pChart, and most JS-bridged solutions. They own the canvas. You get a finished PNG file back and composite at the file or page level, never at the pixel level. fastchart's two-path design covers both:

// Path 1: "give me a file."
(new FastChart\LineChart(800, 600))
    ->setSeries([['data' => $values]])
    ->renderToFile('/tmp/line.png');

// Path 2: "draw onto my canvas." Two charts side by side on the same image.
$canvas = imagecreatetruecolor(1600, 900);

(new FastChart\LineChart(1600, 900))
    ->setTitle('Daily active users')
    ->setSeries([['data' => $values]])
    ->setPlotRect(80, 60, 720, 820)
    ->draw($canvas);

(new FastChart\BarChart(1600, 900))
    ->setTitle('Quarterly revenue')
    ->setSeries([['data' => $bars]])
    ->setPlotRect(880, 60, 1520, 820)
    ->draw($canvas);

// Stamp something gd-native on top.
$font = '/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf';
imagettftext($canvas, 24, 0, 20, 40, $white, $font, 'Dashboard');

imagepng($canvas, '/tmp/dashboard.png');

A four-tile dashboard, a chart embedded in a PDF page, a chart and its legend baked together on a sprite, same primitives, no separate render passes, no temp files.

Performance

Every chart type renders under 100 ms at 1920×1080 on a single core. The lighter types break 100 renders per second per core at dashboard-tile size (640×480). Numbers from my workstation (Intel i9-13950HX, PHP 8.4 NTS), default font and DPI.

Chart	640×480 ms	1920×1080 ms	1080p ops/sec
AreaChart	24	76	13
BarChart	39	84	12
BoxPlot	16	60	17
BubbleChart	13	62	16
ContourChart	9	52	19
Funnel	14	52	19
GanttChart	18	61	16
GaugeChart	10	60	17
Heatmap	9	56	18
LineChart	21	66	15
LinearMeter	9	50	20
PieChart	13	59	17
PolarChart	10	53	19
RadarChart	15	61	16
ScatterChart	17	60	17
StockChart	21	68	15
SurfaceChart	8	50	20
Treemap	18	60	17
Waterfall	18	61	16

These are not "we render faster than Chart.js running in Puppeteer" numbers. Headless-browser rendering is slow for completely different reasons (process startup, JS runtime, layout, paint). The honest framing is that fastchart removes the JS-render path entirely from server-side image generation. The benchmark is a sanity check that the C path is fast enough to stop reaching for a sidecar, not a marketing claim.

Bench source is at docs/bench/bench.php. Reproduce locally with php -d extension=gd -d extension=./modules/fastchart.so docs/bench/bench.php.

Install

pie install iliaal/fastchart

Or build from source against the PHP install you want to extend:

phpize
./configure --enable-fastchart
make -j
make test
sudo make install

PHP 8.3 or newer, plus ext/gd. fastchart declares ZEND_MOD_REQUIRED("gd") so the engine orders MINIT correctly regardless of php.ini / conf.d / -d extension= load order. (Earlier 0.1.0 didn't, and docker-php-ext-enable's alphabetical conf.d ordering caused fastchart to load before gd. That was the only thing 0.1.1 fixed.)

Twenty years later

The 2006 ext-gdchart was a hundred lines of glue around roughly 1,000 lines of upstream library. Single chart family, single output format, a tiny config surface. It worked. It died the moment its upstream did.

The bet with fastchart is the opposite: own enough of the substrate that the project's lifespan isn't bound to anything external besides gd, which has been in PHP since 4.0.0. Nineteen chart types, two symbol types, the whole stack lives in this repo. No third-party chart library to outlast, no microservice to keep alive, no JS toolchain to drag along.

Twenty years between PHP charting extensions is long enough.

mdparser: a native CommonMark + GFM parser for PHP

Ilia Alshanetsky — Wed, 06 May 2026 14:33:28 +0000

Several of my projects do heavy markdown parsing. Comment rendering, documentation pipelines, content management. The volume keeps growing, and I've been hitting the point where pure-PHP parsers (Parsedown, league/commonmark, cebe/markdown, michelf) just can't keep up. They're solid libraries, but parsing thousands of documents per request or chewing through 200 KB files in interpreted PHP is slow no matter how well the code is written.

I wanted something 10x+ faster that could serve as a drop-in replacement for the common cases. The result is mdparser, a native C extension that wraps cmark-gfm (GitHub's CommonMark parser) and exposes it through a clean PHP 8.3+ OO API. I'm releasing it today.

How it works

mdparser vendors a copy of cmark-gfm 0.29.0.gfm.13 directly into the extension's shared object. No external library to link against, no cmake, no runtime dependencies. The entire cmark-gfm codebase compiles alongside the PHP wrapper into a single .so (or .dll on Windows). Four cherry-picked commits from cmark upstream close the 0.29-to-0.31 spec gap, giving full CommonMark 0.31 conformance: 652 out of 652 spec examples pass.

The PHP API is intentionally small. Two classes, one exception:

use MdParser\Parser;
use MdParser\Options;

// Defaults: safe mode on, GFM extensions on.
$parser = new Parser();
echo $parser->toHtml('# Hello');

// Or the static shorthand:
echo Parser::html('# Hello');

// Custom options via named arguments:
$parser = new Parser(new Options(
 smart: true,
 footnotes: true,
 sourcepos: true,
));

// Three output formats:
$html = $parser->toHtml($markdown);
$xml = $parser->toXml($markdown);
$ast = $parser->toAst($markdown); // nested PHP arrays

Options is final readonly with 17 boolean fields. The Parser constructor translates those bools into cmark's internal bitmask once, so every subsequent parse call is pure cmark work with zero per-call overhead. Static factory presets (Options::strict(), Options::github(), Options::permissive()) cover common deployment patterns.

If you're migrating from Parsedown's line() or cebe/markdown's parseParagraph(), there's toInlineHtml(): inline-only HTML without the wrapping <p> tags. Useful for chat messages, table cells, and short user-facing strings.

Performance

This was the primary motivation. Measured on PHP 8.4 with each parser in its default configuration:

Parser	Small (200 B)	Medium (1.8 KB)	Large (200 KB)
mdparser	30,447 ops/s	5,697 ops/s	105 ops/s
Parsedown	1,651 ops/s (18x slower)	325 ops/s (17x)	6 ops/s (17x)
cebe/markdown (GFM)	1,350 ops/s (22x)	374 ops/s (15x)	6 ops/s (16x)
michelf (Extra)	1,006 ops/s (30x)	209 ops/s (27x)	5 ops/s (19x)

15-30x faster, from 200-byte chat messages to 200 KB documents. Your absolute numbers will differ by hardware, but the ratios hold. mdparser processes roughly 100 full CommonMark-spec-sized documents per second on a single core. The pure-PHP parsers manage 5-6.

The benchmark uses hrtime(true) around each parse call, 200 iterations with warm-up, trimmed mean to filter GC pauses. Reproducible scripts are in the bench/ directory.

Feature comparison

mdparser covers CommonMark core plus all five GFM extensions. Here's how it stacks up against the pure-PHP alternatives:

Feature	mdparser	Parsedown	league/cm	cebe GFM	michelf Extra
CommonMark core	full	partial	full	partial	partial
GFM tables	yes	yes	via ext	yes	via Extra
Strikethrough	yes	yes	via ext	yes	no
Task lists	yes	no	via ext	no	no
Autolinks	yes	yes	via ext	yes	no
Tag filter	yes	yes	via ext	partial	no
Smart punctuation	yes	no	via ext	no	no
Footnotes	yes	Extra	via ext	no	yes
Sourcepos	yes	no	yes	no	no
XML output	yes	no	no	no	no
AST output	yes (arrays)	no	yes (objects)	no	no

What mdparser doesn't do

mdparser is scoped to what cmark-gfm supports: CommonMark core plus five GFM extensions. It doesn't cover definition lists, abbreviations, attribute syntax, heading permalinks, table of contents, YAML front matter, mentions, LaTeX math, emoji shortcodes, or custom containers. If you need those, league/commonmark is the right choice. It's the most featureful pure-PHP option and actively maintained. Speed doesn't help if the feature you need isn't there.

Compatibility

mdparser builds and tests on PHP 8.3, 8.4, and 8.5 across Linux (x86_64), macOS (arm64/x86_64), and Windows (x86/x64, both TS and NTS). CI runs on all three platforms, with an ASAN job on Linux to catch memory issues. Pre-built Windows DLLs ship with each GitHub release.

Installation

pie install iliaal/mdparser

PIE handles the download, phpize, configure, make, and install. On a minimal PHP image you'll need git, bison, and libtool-bin as build dependencies.

From source:

git clone https://github.com/iliaal/mdparser.git
cd mdparser
phpize && ./configure --enable-mdparser
make -j && sudo make install