u/Ilia0001

I maintain fastjson, a native PHP extension that drops in next to ext/json with a namespaced fastjson_* API and the same flag/error model. 0.3.0 just landed.

The problem. ext/json leaves a lot of performance on the table on both encode and decode paths. High-throughput PHP APIs spend a non-trivial fraction of CPU budget in JSON serialization. The two existing escape hatches are uncomfortable: simdjson_php is decode-only and not API-compatible, and rolling a custom validator is fragile.

The shape. fastjson exposes fastjson_encode/decode/validate behind a namespaced API that mirrors ext/json's. Backed by yyjson 0.12.0 (MIT). PHP 8.3 minimum; coexists with ext/json so adoption is opt-in per call site, not a repo-wide flag day.

Numbers. Full simdjson_php canonical 14.8MB corpus, 15 files, i9-13950HX, release builds of both PHP (8.6.0-dev) and fastjson:

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

Visual side-by-side (also includes ext/json (https://github.com/php/php-src/pull/17734) SIMD encode and simdjson_php on the same PHP build): https://iliaal.github.io/fastjson/baseline.html

Drop-in mechanics. fastjson_* signatures track ext/json. JSON_* flags and JSON_ERROR_* constants match byte-for-byte; fastjson_last_error mirrors json_last_error. Migration is search-and-replace.

Honest tradeoff. Decode and validate hold the yyjson doc in memory alongside results. Decode peak heap is ~1.7× ext/json's. Validate peak is ~101× ext/json's streaming validator (constant ~80 bytes), already 2.7× better than yyjson's stock read path thanks to a vendored patch. Encode is one-stage (direct write into smart_str), peak ~1.06× ext/json. If you are validate-heavy on huge inputs under tight memory_limit, the memory profile is a real consideration. For most callers the speedup wins.

What 0.3.0 does:

• ~36% speedup on object-heavy decode under JSON_INVALID_UTF8_IGNORE/SUBSTITUTE. A no-alloc UTF-8 validator scans each string and object key first; the sanitizer only runs on byte sequences that actually need replacement. Valid UTF-8 inputs no longer pay a per-string sanitize allocation and copy.
• HEX flag rewrites (JSON_HEX_TAG/AMP/APOS/QUOT) now scan first and skip the rewrite entirely when no candidates exist. ~4× faster on the no-hit case (532 µs to 125 µs on 1k strings), ~13% regression on the all-hit case from the extra scan pass.
• dw_emit_double checks the cheap range bound before calling floor(). Non-integer or out-of-range doubles in number-heavy arrays no longer pay libm per element.
• Two correctness fixes: a use-after-free in fastjson_encode for PHP 8.4 objects whose property has a SET hook but no GET hook (engine's trivial-read fast path returns a borrowed pointer; the previous stash logic freed it), and a 32-bit zend_long overflow on the integer-valued-double shortcut that could emit INT32-saturated garbage for things like fastjson_encode(1e10).
• ext/json parity for integer-valued doubles between 1e15 and 1e17. fastjson_encode(1e16) now emits "10000000000000000" instead of yyjson's "10000000000000000.0", matching json_encode.

Install via PIE:

pie install iliaal/fastjson

Repo: https://github.com/iliaal/fastjson

Open to feedback on flag coverage and edge cases, especially anyone running JSON_INVALID_UTF8_IGNORE or the HEX flags on hot paths.

Six months of daily Claude Code use convinced me the agent doesn't lack capability. It lacks process. It can write a React component or trace a segfault, but it won't ask "did I verify this actually works?" before declaring victory, and it won't split a 400-line diff into reviewable chunks.

whetstone is a plugin that fixes that. 30 skills, 19 agents, 22 commands. Skills are compact instruction sets that load on keyword match, so the agent picks up the relevant discipline for the task it's actually running.

The debugging skill blocks a fix until the root cause is identified with file-and-line evidence two levels deep in the call chain. Reproduce first, one hypothesis at a time, escalate after three failed attempts instead of guessing forever. The code-review skill runs spec-compliance first, then quality, and dispatches parallel specialist agents (security, performance, database) when a diff crosses the size threshold. The writing skill keeps a banned-vocab list and a five-dimension rubric every piece of prose passes through.

The workflow is five commands. /ia-brainstorm interviews you to surface hidden requirements. /ia-plan turns that into atomic tasks with file paths. /ia-work executes with task tracking and verification gates. /ia-review runs the multi-agent review. /ia-compound captures what you solved as searchable docs the next session can find. Each works standalone.

https://github.com/iliaal/whetstone

I posted this in r/laravel last week. u/equilni's reply:

> Looking at the repo, this looks like it could be used for plain PHP too. I suggest posting in that sub as well.

So here it is. Original thread: https://www.reddit.com/r/laravel/comments/1t84fu4/mdparser_030_native_php_commonmark_gfm_parser/

I build native PHP extensions when pure-PHP solutions become a bottleneck. mdparser is the markdown one. It wraps embedded cmark-gfm (CommonMark 0.31, all 652 spec examples pass) and ships as a single .so on Linux/macOS or .dll on Windows. PHP 8.3 minimum.

If your app renders markdown on every request, comment threads, docs, CMS pages, forum threads, transactional mail, pure-PHP parsers become a measurable fraction of request time. mdparser is for that hot path.

What's in it:

• GFM extensions: tables, strikethrough, task lists, autolinks, tagfilter (XSS-safe HTML sanitization)
• Smart punctuation, footnotes, safe mode, heading anchors, nofollow links
• Three output formats from one parser: HTML, CommonMark XML, and a PHP AST (nested arrays). AST output is rare in PHP markdown libraries; useful if you want to walk the tree before rendering, or sanitize at the structural level instead of post-hoc on HTML.

Performance against the major pure-PHP parsers, 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 (Markdown Extra)	1,006 ops/s (30x)	209 ops/s (27x)	5 ops/s (19x)

15-30× faster across the board, from short messages up to full 200 KB spec documents. league/commonmark is the closest competitor and has slightly different positioning (more extensions via opt-in); numbers and methodology in bench/README.md.

Install:

pie install iliaal/mdparser

API:

use MdParser\Parser;
$parser = new Parser();
$html = $parser->toHtml($markdown);
$ast  = $parser->toAst($markdown);

Blog post with the full benchmark methodology and comparison data: https://ilia.ws/blog/mdparser-a-native-commonmark-gfm-parser-for-php Repo: https://github.com/iliaal/mdparser

Happy to answer questions, especially about the AST output, the cmark-gfm postprocess interactions (heading-anchor positioning under raw HTML, nofollow-aware HTML scanning), or anything PHP-extension-side.

I build native PHP extensions when pure-PHP solutions become a bottleneck. mdparser is the markdown one.

If your Laravel app renders markdown on every page load (comment threads, mailables, Filament fields, content pages) pure-PHP parsers like league/commonmark and Parsedown become a measurable share of request time. mdparser is a C extension that parses CommonMark and GFM 15-30× faster on the same documents. league/commonmark is a fine default for most apps; the pain shows up when markdown rendering is on the hot path.

What it does:

• GFM extensions: tables, strikethrough, task lists, autolinks, tagfilter (XSS-safe HTML sanitization)
• Smart punctuation, footnotes, safe mode
• Output as HTML, XML, or PHP AST (the AST output is rare in markdown libraries; useful if you want to walk the tree before rendering)

Where it slots into a Laravel codebase:

• Mailable rendering. The path that ships with Laravel goes through league/commonmark under the hood, so swapping in mdparser for high-volume transactional mail is a one-line change in the renderer binding.
• Filament markdown fields, rendered on the backend.
• Forum or comment rendering middleware.
• Documentation or static page generation.

Install:

pie install iliaal/mdparser

API:

$parser = new MarkdownParser();
$html = $parser->toHtml($markdown);
$ast  = $parser->toAst($markdown);

Blog post with the full benchmark methodology and comparison data: https://ilia.ws/blog/mdparser-a-native-commonmark-gfm-parser-for-php

Repo: https://github.com/iliaal/mdparser

Happy to answer questions about Laravel-specific integration, mailables especially.

I've maintained php_excel since 2008. 2.0 shipped in April as the first ground-up rewrite, and 2.0.1 just landed on May 3.

The problem it solves: PhpSpreadsheet builds the whole DOM in PHP memory. On a 50K-row spreadsheet you're looking at ~790 MB resident before you've called save(). In a 128 MB FPM pool that means OOM on anything past trivial. OpenSpout streams, but it can't write conditional formatting, formulas, rich text, or .xls.

php_excel wraps LibXL through a native C extension. LibXL (libxl.com) is a commercial C++ library by Andrew Karasyov, not mine; you acquire it separately. php_excel is the PHP binding.

Quick comparison. PhpSpreadsheet is the most feature-complete pure-PHP option. OpenSpout fills a streaming niche. php_excel is the C-extension answer for when you need both speed and full Excel features.

What 2.0 changed:

• PHP 8.3 / 8.4 / 8.5 / master, dropped older versions
• LibXL 4.6.0+, newer features gated at compile time
• 12 classes (6 new: ExcelRichString, ExcelFormControl, ExcelConditionalFormat, ExcelConditionalFormatting, ExcelCoreProperties, ExcelTable)
• 399 typed parameters, 277 typed return values, full arginfo coverage from a stub-driven build
• Installable via PIE

Benchmarks against PhpSpreadsheet 5.5.0, PHP 8.4.19 NTS:

Rows	Cells	php_excel	PhpSpreadsheet	Speed
1,000	20K	0.05s / 85 MB	0.45s / 162 MB	10×
10,000	200K	0.55s / 153 MB	4.59s / 282 MB	9×
50,000	1M	2.72s / 508 MB	24.7s / 790 MB	9×
100,000	2M	5.37s / 908 MB	51.1s / 1,415 MB	10×

Read perf is similar: 8-9× faster than PhpSpreadsheet, 3× faster than OpenSpout (with proportional memory trade-off vs OpenSpout's flat 130 MB).

2.0.1 is a hardening pass: extensive error checking and input validation across the C/PHP boundary.

Install:

pie install iliaal/php-excel --with-libxl-incdir=/path/to/libxl/include_c --with-libxl-libdir=/path/to/libxl/lib

Full writeup with methodology: https://ilia.ws/blog/php-excel-2-0-the-c-extension-for-excel-that-php-should-have-had-all-along

Repo: https://github.com/iliaal/php_excel

Six days ago I tagged 0.6.0 of php_clickhouse, a soft fork of the SeasClick extension (which stopped accepting PRs in 2020). Three releases later (0.7.0, 0.8.0, 0.8.1) I'm calling the extension stable.

The PHP ClickHouse ecosystem has been split between SeasClick (native binary protocol but stalled, no modern types, no ZTS, no TLS in the maintained fork) and HTTP clients like smi2/phpClickHouse (active but ~30-40% slower at high throughput). This fork picks up the native-protocol path with the official clickhouse-cpp v2.6.1 client and brings the modern type surface back.

What landed in the quality cycle:

0.7.0 closed the API gap with smi2/phpClickHouse. Per-call settings, server-side typed parameters via {name:Type} placeholders, progress callback, getStatistics() (rows/bytes/elapsed_ms), structured ClickHouseException with server_code / query_id, insertAssoc(), SQL helpers (databaseSize, showTables, tableSize, etc.), sub-second timeouts. Adopting the native client no longer costs ergonomics.

0.8.0 moved per-Client state from seven file-scope std::map banks onto the zend_object itself. Unblocks ZTS (RoadRunner / FrankenPHP / Swoole / php-pm now work), plugs leaks on script bailout, fixes a refcount bug on the progress callback. Adds streaming reads (selectStream() returns an Iterator + Countable, selectStreamCallback() for unbounded streams), Geo types (Point / Ring / Polygon / MultiPolygon), LowCardinality(Nullable(T)), and Map(K, V) over the full scalar matrix. Pre-built binaries for Linux glibc (x86_64 + arm64) and macOS (x86_64 + arm64) via PIE.

0.8.1 hardened the insert path. The connection now resets on every server-side rejection point (BeginInsert, SendInsertBlock, EndInsert) so a thrown insert no longer wedges the handle with "cannot execute query while inserting". Insert builds native columns one at a time directly from row-major input: peak intermediate PHP memory drops from N_rows × N_cols zvals to one column. Strict full-consumption parsers across Map, narrow-int, Int128 / UInt128, geo, DateTime64 reject coercion-to-zero on bad input. 23 new PHPTs covering all of the above.

One side effect of the new ASan job: it caught a latent UB in clickhouse-cpp's empty-string-view memcpy path. Submitted upstream and merged as ClickHouse/clickhouse-cpp#489 on April 27.

Install on supported platforms (Linux glibc + macOS, NTS, PHP 8.4 / 8.5):

pie install iliaal/php_clickhouse

TLS variant builds from source: pie install iliaal/php_clickhouse --enable-clickhouse-openssl.

Blog post with the full breakdown: https://ilia.ws/blog/php-clickhouse-0-8-1-three-releases-later-stable Repo: https://github.com/iliaal/php_clickhouse

Happy to take questions, especially from anyone running ClickHouse-from-PHP at production volume.

A while back I pushed a small PECL extension that wrapped libstatgrab and exposed CPU, memory, disk I/O, network, and process statistics to PHP. It sat untouched for most of the PHP 5/7 era and stopped building cleanly on PHP 8 a few years back. I shipped 2.2 today, a full modernization of the binding for PHP 8.0 through 8.5 against libstatgrab 0.92+.

The reason to revive it: nothing on the PHP side has replaced it. If you need system stats from PHP, you are typically choosing between three options.

• Shell out to w, vmstat, df, ps. The output format drifts between OS releases, and you end up writing a per-tool parser.
• Parse /proc by hand. Linux-only, every file (meminfo, loadavg, diskstats, net/dev) has its own format and edge cases.
• Run a separate stats daemon and hit it over a socket. Adds a daemon to deploy and keep running.

libstatgrab itself is the right primitive: a cross-platform C library that handles /proc on Linux, kvm on FreeBSD, and the Mach host_* APIs on macOS, and exposes one typed surface. It just needed a PHP binding that worked on a current interpreter.

The 2005 procedural API is preserved (sg_cpu_percent_usage, sg_memory_stats, etc.) for drop-in compatibility, with a new OO surface (Statgrab::cpu(), ::memory(), ::processes()) on top.

While running ASan on the new test suite I caught a memory leak in libstatgrab's shutdown path. Patch submitted upstream; pending review. The repo carries a vendored libstatgrab 0.92.1 with the local fix in the meantime. Build with --with-statgrab=bundled to get a single .so with no runtime dependency on libstatgrab.so. Useful in any deployment where you don't want to require libstatgrab as a system package.

Install:

pie install iliaal/statgrab

Or pecl install statgrab if you are still on the legacy installer. Source build and the bundled-libstatgrab path are in the README.

Repo: https://github.com/iliaal/statgrab Full write-up: https://ilia.ws/blog/its-alive-statgrab-returns-after-20-years