DEV Community: Nazar Boyko

The Models Read the Release Notes. I Measured the Runtime.

Nazar Boyko — Sat, 10 Oct 2026 14:13:00 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I've written PHP for most of my career and Go for the last few years, and in code reviews I repeat the same memory rules everyone repeats. A goroutine is 2 KB, don't worry about it. An int64 to int64 map entry is 16 bytes. unset() gives the memory back. Use map[K]struct{} for sets, because struct{} is free. I never checked any of them. Why would I? They've always been true.

Except some of them aren't anymore. PHP 8.2 stopped storing keys in packed arrays (php-src #7491). Go 1.24 threw out its old map implementation for Swiss Tables. Go 1.19 started picking the initial goroutine stack size from what it had seen so far. The rules stayed in our heads; the runtimes moved on. So I got curious: when a model answers a memory question, what is it actually remembering? The rule, the runtime, or the specific version?

Let's play. Guess before you scroll. Both maps hold one million keys:

set := make(map[int64]struct{})
for i := int64(0); i < 1_000_000; i++ {
    set[i] = struct{}{}
}

flags := make(map[int64]bool)
for i := int64(0); i < 1_000_000; i++ {
    flags[i] = true
}

How does the heap held by set compare with flags?

A. set is about 10% smaller
B. set is about half the size of flags
C. About the same
D. It depends on the Go version

Pick one. The answer, with the measured number, is waiting in Findings. If you enjoy this kind of thing, all seventeen cases are on this page: you pick an option, then you see what the runtime actually did.

Seventeen cases in total: seven about PHP arrays, five about Go maps, five about goroutine stacks. Three of them are controls, cases where the old rule is still right. Without those, a model could score well just by betting against every rule, and I didn't want to reward cynicism.

One thing I was strict about: not a single "correct answer" came from a blog post, including mine. A small harness builds each structure and reads memory_get_usage() in PHP or runtime.MemStats in Go. A GitHub Actions matrix runs it three times on PHP 8.1 through 8.4 and Go 1.23 through 1.26. If you don't trust my numbers, and you shouldn't have to, one command reruns everything:

sh measure/run.sh

Each case went to the models three times, as three separate Kaggle tasks:

cold: just the code and the question,
versioned: the same, plus the runtime version,
evidence: the same, plus one measured number from a neighbouring case.

Models answer in JSON: an option, an estimate in MB or KB, which mechanism they think explains it, and a confidence from 0 to 100. Plain code does the scoring, no LLM judge anywhere. A third of the point for the right option, a third for an estimate within 0.67x to 1.5x of the measured value, a third for the right mechanism.

Models Tested

Twelve models from Kaggle's list. I picked them along three lines: a small and a flagship model from each vendor, a newer and an older generation of the same vendor (did newer training data pick up Go 1.24 maps?), and a few open-weight models.

gemini-3.5-flash-lite, gemini-3.8-flash, gemini-3.1-pro-preview, gemini-2.5-flash, claude-haiku-5-5, claude-opus-5-5-default, claude-haiku-4-5-20251001, gpt-5.4-nano-2026-03-17, gpt-6.1-sol, gpt-oss-120b, gemma-4-31b-it, qwen3-coder-480b-a35b-instruct.

Nothing returned a 404 and I swapped nothing out. Eleven of the twelve have a complete run on all three tasks. The one that doesn't is gemini-3.1-pro-preview: 13 cold questions cost $0.89, one of its replies ran to 22,064 output tokens, and Kaggle gives my account $10 of model calls a day. Its partial replies are in the repository, but it's in none of the tables below.

There's also a thirteenth model in the tables, and I didn't invite it. When you create a task, Kaggle runs it once on gemini-3.7-flash. Those runs are as real as mine, so I kept them.

Findings

First, the answer to the game. On Go 1.23 the struct{} set is about 10% smaller than the bool map (ratio 0.91). On Go 1.24 and later they're the same size (ratio 1.00). So if nobody told you the version, the honest answer is D. Swiss-table maps keep key and value together in one aligned slot, and an empty value saves you nothing. When I put the version in the prompt, exactly 2 of 12 models followed the change: gpt-6.1-sol and claude-opus-5-5-default. Four others did change their answer for Go 1.24, in the wrong direction, to "half the size".

The two best models lost the same question, and it was a control. Here's the setup. I start 100,000 goroutines that each hold an 8 KB array, run a GC, then start 100,000 idle goroutines, and ask how much stack each idle one takes. The old rule says 2 KB. The Go 1.19 release notes say the runtime sizes new stacks from the average it has seen, which points at 16 KB. I measured 2.0 KB, on Go 1.23 through 1.26. Then I changed one thing: I let the first batch exit before starting the idle batch. Now each idle goroutine takes 16.0 KB.

Both numbers are right, and the runtime source explains why. newproc1 gives a brand-new goroutine a stack of stackMin, which is 2 KB. gfget hands out the descriptor of a finished goroutine again, and that one gets startingStackSize, the adaptive size. The links point at the current release, Go 1.27; the four versions I measured have the same two lines.

gpt-6.1-sol got 56 of 59 questions right. The three it missed are this control, once per task, at a stated confidence of 98 or 99. claude-opus-5-5-default missed it three times too. Both basically recited the release note back to me, with arithmetic. Across 36 runs, a model kept the control and lost its twin 19 times, did the reverse 14 times, and got both right twice. Both of those were gemini-3.5-flash-lite.

This is the part that changed how I'll use these models for runtime questions. A strong model knows the changelog better than I do. It also applies the changelog in places where the code doesn't.

The leaderboard. Task score, one complete run per model and task. The row without a slug is me, cold condition only.

model	cold	versioned	evidence	mean
`gpt-6.1-sol`	0.94	0.95	0.95	0.95
`claude-opus-5-5-default`	0.90	0.95	0.95	0.94
`gemini-3.8-flash`	0.84	0.86	0.79	0.83
`claude-haiku-5-5`	0.78	0.83	0.81	0.81
`gemini-3.7-flash`	0.80	0.81	0.78	0.80
`gemma-4-31b-it`	0.69	0.70	0.71	0.70
`gemini-2.5-flash`	0.67	0.68	0.65	0.67
author, cold only	0.67
`gpt-oss-120b`	0.53	0.57	0.56	0.55
`claude-haiku-4-5-20251001`	0.57	0.51	0.48	0.52
`gemini-3.5-flash-lite`	0.51	0.49	0.49	0.50
`qwen3-coder-480b-a35b-instruct`	0.41	0.44	0.52	0.46
`gpt-5.4-nano-2026-03-17`	0.37	0.35	0.44	0.39

Within a family, the newer generation wins by a lot: claude-haiku-5-5 at 0.81 against claude-haiku-4-5-20251001 at 0.52, gemini-3.8-flash at 0.83 against gemini-2.5-flash at 0.67. The older Gemini also burned more than twice the output tokens per question (5,445 against 2,235) to get the lower score. Not one reply failed to parse.

Version sensitivity. Four cases have a measured answer that flips with the version: three between PHP 8.1 and 8.3, one between Go 1.23 and 1.24. I asked each of those twice, once per version. gpt-6.1-sol and claude-opus-5-5-default got all four pairs right. gemini-3.8-flash and claude-haiku-5-5 got three, gemini-3.7-flash two, gpt-oss-120b one. Six models got none. All six said "2.5x" for the reversed array on PHP 8.1 and again on PHP 8.3, where I measured 1.25x and 2.50x. The Swiss-table case was the hardest (2 of 12 models), the SplFixedArray case the easiest (6 of 12).

"It depends" is a rare answer. With no version in the prompt, the right answer to those four cases is "it depends on the version". Models picked it in 13 of 48 replies. Most just answered for the newest runtime and moved on. My favourite: claude-opus-5-5-default wrote "Before PHP 8.2 the ratio was about 1.25x" in its reasoning, and then chose the PHP 8.2 option anyway.

Confidence. The stated number told me very little. Seven of the twelve models put 80 or more on every single wrong answer they gave. gemini-3.5-flash-lite and qwen3-coder-480b-a35b-instruct did it 32 times each, gemini-2.5-flash 22 times, gemma-4-31b-it 19. Only two models dropped by more than five points when they were wrong: claude-opus-5-5-default from 77.5 to 70.2, and claude-haiku-5-5 from 70.7 to 61.6. Haiku 5.5 put 80 or more on none of its 17 wrong answers, which is more self-awareness than I expected from a small model.

Right answer, wrong reason. qwen3-coder-480b-a35b-instruct picked the measured answer 27 times and explained 11 of those with a wrong mechanism. For gpt-5.4-nano-2026-03-17 it was 6 of 16. For the top two it was 0. If I had scored on the answer letter alone, none of this would have shown up.

Evidence barely helped. Handing a model one measured number from a neighbouring case moved almost nothing. From cold to evidence, the twelve models gained 14 right answers and lost 14.

Ask the same thing twice. Quota errors cut my first pass to pieces, so most models ended up answering many prompts twice. Across 501 pairs of replies to the same prompt, the answer letter matched 82% of the time. gpt-6.1-sol (19 of 19) and claude-opus-5-5-default (25 of 25) never changed their minds. gpt-5.4-nano-2026-03-17 and gemini-2.5-flash matched only 65% of the time. With one run per model, a gap of a few points on this leaderboard can be noise, and you should read it that way.

Which rules are dead, and which refuse to die. Not one model chose the folklore explanation for unset() freeing memory, for the 16-byte map entry, or for delete giving a map's memory back. Those rules are gone from the training data, it seems. The rules that were once true are the ones that live on. "SplFixedArray saves memory" was the chosen mechanism in 22 of 60 replies and "struct{} is free" in 21 of 60. I measured SplFixedArray at about half the memory of a plain list on PHP 8.1 (ratio 0.48) and about the same on PHP 8.3 (ratio 0.95). That rule held right up to PHP 8.2 and then quietly stopped.

In their own words.

gpt-6.1-sol on the control, confidence 98, measured 2.0 KB:

Since Go 1.19, adaptive stack sizing uses the average stack space scanned during the last GC, adds a stack guard, and rounds up to a power of two. The first batch dominates that average with live frames exceeding 8 KB, so the second batch starts with approximately 16 KB stacks.

qwen3-coder-480b-a35b-instruct on the game from the top, measured ratio 0.91 on Go 1.23 and 1.00 on Go 1.24:

struct{}{} takes zero bytes, so set only stores keys while flags stores both keys and bool values. Each bool is 1 byte, so flags uses roughly twice the memory for values.

gpt-5.4-nano-2026-03-17 on 100,000 three-property objects against 100,000 three-key arrays, where the arrays measured 3.12 times the memory on PHP 8.3:

In PHP, each $objects element is an object with overhead (zval + object header/handlers/property metadata), while $arrays elements are arrays with overhead too (zval + HashTable + buckets). For 3 fields, these overheads are of the same order, so memory_get_usage() is typically close.

A few more things the harness measured. All of these held on every version I ran:

unset() on every second element of a one-million-element list leaves memory_get_usage() exactly where it was (ratio 1.00 on PHP 8.1 and 8.3).
An int64 to int64 map holds about 38.1 bytes per entry on Go 1.24. The rule says 16.
Deleting every key and clear(m) both keep the full map after a GC (36.38 MB on Go 1.24).
A goroutine holding an 8 KB local array takes 16.0 KB of stack. "2 plus 8" would suggest 10.
One million two-element arrays [$i, $i] take 222.0 MB on PHP 8.3 and 390.59 MB on PHP 8.1. A pair of integers is 32 bytes, in theory.

My own score. 🤭 Before I looked at a single measurement, I answered the cold questions myself. I scored 0.67 on the same scale as the models: 10 of 17 answer letters, 14 of 17 mechanisms, 10 of 17 estimates inside the tolerance. My mean confidence was 80.5 when I was right and 70.0 when I was wrong. The cases that sting are P1, P4, P8 and G3. On all four the measured answer was "it depends on the version", and I did exactly what most of the models did: answered for the version I use, got the mechanism right on three of them, and never once said "it depends".

The quota, for whoever tries this next. Kaggle's model proxy reserves the worst-case cost of every call against a $10 daily quota: the model's maximum output at its output price, which is $2.56 for a single claude-opus-5-5-default call. I started twelve models at once and 160 questions came back refused. The fix was max_tokens on every call and no more than four models at a time. All 71 run files together cost $7.84.

What I'd measure next. Laravel collections on top of PHP arrays. The same harness on Alpine with musl, where the allocator is different. Goroutine stacks under real request handlers instead of synthetic frames.

Limits, so nobody has to dig for them. Seventeen cases and one scored run per model and task; the repeated replies above come from a partial first pass. One runner type per version (GitHub's ubuntu-24.04). Replies that never parse score zero and are counted; there were none. The Kaggle Benchmarks library sends no temperature to the model proxy, so a rerun can differ. Every call carries max_tokens=32768; the longest reply among the scored runs used 22,329 tokens. gemini-3.1-pro-preview has no complete run. The human baseline is one person, and he's biased.

My Benchmark

Benchmark and leaderboard: https://www.kaggle.com/benchmarks/nb9300/memorytrap-bench-php-arrays-go-maps/leaderboard
Tasks: memorytrap-cold, memorytrap-versioned, memorytrap-evidence
Guess-first page with every case: https://nazboyko.github.io/memory-trap-bench/
Code, measurements, raw model replies and the full report: https://github.com/nazboyko/memory-trap-bench
Rerun the measurements: sh measure/run.sh

The first four of twelve columns; the full board is behind the leaderboard link above.

Credits: the Kaggle Benchmarks library and platform ran the models; setup-php and setup-go gave me eight runtime versions in CI; the PHP and Go release notes, the pull request and the Go runtime source linked above explain the changes the harness measured.

Tabs to Trails: My Unread Tabs Became Walks, Made on My Own Laptop

Nazar Boyko — Fri, 09 Oct 2026 18:04:03 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

My reading system is a row of browser tabs I opened because the title looked worth my time, then kept open for weeks, because reading takes a chair and a chair is where I spend the day already.

Tabs to Trails turns those tabs into walks. A bookmarklet called "Walk this tab" drops the page you're on into a list, and each row shows how many minutes it takes to hear. When I've got twenty minutes, I pick 20. The app ticks what fits, oldest first, says how each piece will be read ("in full", "condensed from 27 min", "part 1 of 3"), and my laptop makes one MP3 of about that length. Gemma 4 rewrites the text for the ear and the Kokoro voice reads it, both on my machine. I scan a QR code with my phone, download the file, and put the phone in my pocket.

Everything the walk needs is inside the MP3: a short intro, the piece, a chime at the measured middle with "You're halfway. If you're walking out and back, turn around now.", and one question for the way home. The phone needs no app and no Wi-Fi once the file is on it. I set one rule for the design: the app has to be done with me before I reach the door. The only dark screen in the product is the phone's player, and it says "Pocket your phone." and little else.

Three things set it apart from "article to podcast". You bring the content, the thing you already meant to read. The length of your walk shapes it. And it stays faithful: the voice reads prose that fits as written, Gemma condenses only what doesn't fit, and a number guard checks every number in the rewrite against the source. Code blocks and tables are described rather than read, because a code block read aloud is noise.

Demo

Listen to two finished walks on the project page: my own DEV post, asked for 10:00 and measured 10:15, and part one of Thoreau's "Walking", asked for 20:00 and measured 19:39.

A note on the article in the video. It is "Every Software Developer Has Blamed…" by @sylwia-lask. I picked it as a real-world test, and about 20 seconds of the audio version made it into the video. I hope Sylwia doesn't mind me using her post as the example 😇😇😇

Go read the full post:

Relatable tech humor and shared grievances

Sylwia Laskowska

Oct 8

Every Software Developer Has Blamed…

#discuss

150

112

4 min read

Code

nazboyko / tabs-to-trails

Turn your reading backlog into a walk: a local Gemma 4 and Kokoro make an MP3 sized to your walk.

Tabs to Trails

Turn your reading backlog into a walk.

Save tabs now. Walk them later.

Tabs to Trails keeps what you mean to read, measured in walking minutes. When you have twenty minutes, pick 20 and it proposes what fits. Your computer turns that into one MP3 of that length: Gemma 4 rewrites the text for listening and the Kokoro voice reads it, both on your own machine. You scan a QR code, put the phone in your pocket and go.

The file holds everything the walk needs: a short intro, the reading, a chime and a cue at the halfway point so you know when to turn around, one question for the way home, and a sign-off. Its chapters let the phone's own player resume and skip, and an audiobook copy (.m4b) is one tap away. Once the file is on the phone, the walk needs nothing else.

…

View on GitHub

Node and TypeScript: a Hono server, a React front end, Gemma 4 through Ollama, Kokoro-82M through kokoro-js, ffmpeg for the MP3. Gemma 4 and Kokoro-82M are Apache-2.0; the full credits with licenses are in the README.

How I Built It

The pipeline:

link or text, saved to the list and read once
  -> picked by the walk's length
  -> plan: in full, or condensed to a word budget
  -> Gemma 4 rewrite per section, number guard
  -> Kokoro voice per sentence group
  -> measure, fit once, place the halfway cue
  -> MP3 + script + QR code

Every stage writes into one folder per walk, so a build can stop and pick up where it was. I tested that with kill -9 in the middle of the voice stage; on restart the server said "Picking up 1 unfinished walk" and carried on from the third section.

Twenty minutes is not twenty minutes

The length is the product, so I measure it instead of trusting a words-per-minute guess. That guess was wrong in two places.

The voice first. My calibration read a smooth 250-word passage at 188.7 words per minute, and then my own DEV post at 10 minutes came out at 10:42. Across that one post the same voice went from 130 to 174 words per minute per section, because numbers, colons and short paragraphs cost time, while characters per second stayed between 14.3 and 15.9. So the app now calibrates in characters per second, on a passage with numbers in it, and converts that into words per minute for each source.

Then the model. Gemma does not hold a word count on a mild cut: asked for 697 words of a 939-word section, it returned 1,027, longer than the source. Short targets went the other way: asked for 823 of 1,037 words of Thoreau, it wrote 450. So each section gets one guarded shorten or lengthen pass, and whatever it over- or undershoots carries into the next ones. At the end, a fit pass looks at the measured audio once: more than 5% over, it shortens the largest condensed section; more than 8% under, it gives time back to the section that left out the most.

The sample above took my DEV post from 1,726 words to 1,531, with 4.1 seconds of model time and 63.5 seconds of voice on an Apple M5 Max, for 10:15 of audio. Kokoro reads about nine times faster than real time here, so most of the wait is the voice. The app says "Lace up." while it works, and means it.

The number guard

The prompt tells Gemma to use only what is in the source. A small model adds a number from time to time. So after each rewrite, code compares every number in the output with the numbers in that section of the source, spelled-out ones included. A new number sends the section back once, naming it. If it comes back again, the script view draws a dashed outline around it: "Check this number."

The guard once flagged a number that was right: Wikipedia's "one-hundred and fifty percent" came back as "150 percent", and the guard read it as two numbers. It adds them up now. It also misses what it cannot see: "the kid screen got the time" (my evening, in other words) came back as "the kid screen showed the time", with no number involved. The script view's footer says to review anything important, and I mean that.

Read-along that lands on the word

Kokoro speaks in groups of a few sentences, and the app knows where each group starts. Inside a group, my first version spread the time over the sentences by their characters. Measured against the pauses in the audio, those starts were a median 0.3 seconds off, enough to mark the wrong sentence. Now each start moves to the nearest real pause in the voice, preferring longer ones. In the two samples, 231 of 232 sentence starts sit on a pause of at least a quarter second, 40 milliseconds before the voice is loud again.

What broke

Kokoro reads at most 510 phoneme tokens per call and drops the rest without a word. A 294-character chunk of money figures was 1,237 phonemes. Each chunk is now measured with the same phonemizer and split until it fits.
Wikipedia read its footnotes aloud: citation marks like [12] became "twelve". The app strips reference lists and footnotes now, and names what it left out.
The first run read an HTML comment. My own post ends with , and the voice said it.

I took it outside

I didn't film the walks; the video above is a screen recording with the real audio. The 10- and 20-minute walks went without a hitch. On a longer one, a phone call interrupted "Play it here" and I had to open the page and start again, so for long walks the downloaded MP3 or the audiobook file is the better way.

What I cut and what's next

I cut a model comparison with gemma4:e2b, because it wasn't on my laptop and I didn't want to download a model for one table. Next I'd try a pace setting per voice, and test the audiobook file and the reminder on more phones than mine.

Why Does Open Innovation Matter?

The documents I most want to walk with are the ones I can't put in a demo. With open weights on my own machine, the text goes from the clipboard to my disk and nowhere else, so the app works for anything I'm allowed to process on my own machine.

It also changes what a walk costs. There is no meter, so I can make one for a ten-minute errand and throw it away. Paste mode works with the network off once Ollama and the voice are installed.

And anyone can change it. The model is one setting (OLLAMA_MODEL), the prompts are plain text in the repository, and the voice is an Apache-2.0 model you can swap.

Prize Categories

Best Use of Gemma. Gemma 4 (gemma4:e4b through Ollama) does the language work: it condenses sections to a word target, describes code and tables for the ear, rates how much each section matters, and writes the closing question. The code around it keeps it honest: word budgets, the number guard, and a measured fit to the walk's length.

My Six-Year-Old Can't Do Five Things at Once, So His Screen Shows One

Nazar Boyko — Mon, 05 Oct 2026 03:30:12 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My son is six and started kindergarten a month ago. A school morning asks him for five things: eat, brush teeth, get dressed, shoes and jacket, backpack. Breakfast is easy, because breakfast is one pancake with honey and he is very consistent about that. The rest is where it falls apart. He starts getting dressed, remembers his teeth, wants to play, and a few minutes later he is doing all three at once, which means none of them.

I noticed that he is fine with any single step. What he cannot hold is the list. So I built a screen for him that never shows a list.

One Thing is a small app for our home network. I type the routine in plain words. A Gemma 4 model running on my laptop turns it into a short mission with a theme (I went with rockets). I read every step and fix what I don't like. Only after I approve it does it reach the kid screen on the tablet, and there it shows exactly one step at a time: one big emoji, a few words, and one button.

Every rule on that screen comes from something I see on our mornings:

Rule	Why
One step on screen, never a list	The list is the problem.
Every step is read aloud	He is only starting to read.
The button has to be held, not tapped	A six-year-old will happily tap through eight steps in two seconds. Holding it takes a decision.
Brushing teeth is a timer he can't skip	"Until the timer ends" is easier to accept than "until Dad says so".
Nothing ever fails	No red, no "too slow", no points. If a timer runs out, the app asks once whether he is still on it.
The end is always visible	A row of dots with a small rocket on the current one. A routine with a visible end feels shorter.
I approve every mission first	He never talks to the model and never sees a word I have not read.

Demo

Try the kid screen yourself: nazboyko.github.io/one-thing/demo. It plays the built-in sample mission in your browser. Hold the amber button; a quick tap does nothing.

In the video (79 seconds) I type a routine for getting ready to go outside and give it the theme "space walk". Gemma writes the mission in 2.6 seconds. I scroll through the steps, approve it, and the kid screen plays the mission to the finale. The typing is sped up 2x and labeled. The kid screen runs at normal speed, and you can hear it say each step.

Where it stands. This is the first working version, built in one evening. My son has not used it yet. I wanted it finished and checked before it goes in front of him, and I wanted the first try to be a calm one, not one squeezed in before a deadline. Everything in this post is about the idea and how it is built, not about results.

Code

nazboyko / one-thing

A mission board that shows a kid exactly one step at a time. Runs offline on Gemma.

One Thing

A mission board that shows a kid exactly one step at a time. Runs offline on Gemma.

Try the kid screen in your browser: nazboyko.github.io/one-thing/demo (the built-in sample only; writing new missions needs Gemma on your own computer).

Why it exists

I built this for my six-year-old son. Routines with several steps are the hardest part of his day: on a school morning he wants to get dressed, brush his teeth and play all at once, and none of it gets done. A list does not help him, so this screen never shows one.

How it works

A parent describes a routine in plain words and picks a theme.
Gemma 4 runs on the laptop through Ollama and writes a short mission as JSON that has to match a schema. The server tidies it, checks every rule and asks the model once more if something is off.
The…

View on GitHub

How I Built It

The open-source AI at the center is Gemma 4, Google's open-weight model (gemma4:e4b, with thinking turned off). Ollama, an open-source runtime, runs it on my laptop. Around them sits one Go binary that uses only the standard library, with a React front end compiled into it. There is no database, no account and no cloud. Saved missions are JSON files in a folder, and the only network call the app makes is to Ollama on localhost.

parent's words ──> Go server ──> Ollama (Gemma 4, on the laptop)
                       │                    │
                       │   JSON that matches a schema
                       │<───────────────────┘
                 sanitize, validate, retry once
                       │
                 parent reads, edits, approves
                       │
                 tablet shows one step at a time

Getting a small model to return something I can trust. I don't want prose from the model. I want a mission my code can check. So the request to Ollama carries a JSON schema, and Gemma has to answer in that shape. A mission holds three to eight steps, and each step is described like this:

"items": {
  "type": "object",
  "required": ["emoji", "title", "say", "mode", "seconds"],
  "properties": {
    "emoji": { "type": "string" },
    "title": { "type": "string" },
    "say": { "type": "string" },
    "mode": { "type": "string", "enum": ["until_done", "for_duration"] },
    "seconds": { "type": "integer" }
  }
}

A schema guarantees the shape, not the sense. So every answer goes through two more functions. Sanitize fixes what is safe to fix: stray whitespace, Title Case in step titles, a timer outside the allowed range, an "emoji" that is not one. Validate returns plain field errors such as steps[2].title: too many words (at most 6). If any remain, the server sends them back to the model as a follow-up message and asks once more.

Here is what I typed:

Routine: School morning for a 6-year-old: breakfast, brush teeth, get dressed, shoes and jacket, backpack. Brushing teeth is the hardest part, split it into short pieces.

Theme: rocket launch

And this is the raw answer, with only the line breaks tidied:

{
  "title": "Ready for rocket launch",
  "intro": "Captain, it is time to prepare your rocket for today's mission!",
  "steps": [
    { "emoji": "🍳", "title": "Fuel up the rocket", "say": "Captain, eat your breakfast now. Keep fueling up!", "mode": "until_done", "seconds": 60 },
    { "emoji": "🦷", "title": "Polish top deck", "say": "Brush your top teeth. Make them shiny for blast off!", "mode": "for_duration", "seconds": 120 },
    { "emoji": "🦷", "title": "Polish bottom deck", "say": "Brush your bottom teeth. Mission control needs clean teeth!", "mode": "for_duration", "seconds": 120 },
    { "emoji": "👕", "title": "Suit up the rocket", "say": "Captain, get dressed now. Your flight suit is ready!", "mode": "until_done", "seconds": 60 },
    { "emoji": "🥾", "title": "Seal the landing gear", "say": "Put on your shoes and jacket. Time to secure your gear!", "mode": "until_done", "seconds": 60 },
    { "emoji": "🎒", "title": "Pack the rocket", "say": "Captain, pack your backpack. Make sure everything is inside!", "mode": "until_done", "seconds": 60 }
  ],
  "finale": "Mission accomplished, Captain! You are ready for launch!"
}

I would still change one line before approving it. "Keep fueling up!" sounds like "eat more", which the prompt tells the model never to say.

Numbers from my laptop (Apple M5 Max, 64 GB, Ollama 0.35, model already loaded):

Setting	Seconds per mission	Valid on the first try
Thinking off	2.4 on average (1.7 to 2.8)	22 of 22 runs
Thinking on (one run)	11.3	No: breakfast became a ten-minute timed step

The 22 runs went through the server while I tuned the prompt (school mornings, a bedtime, an after-school routine), and the time includes parsing and validation. The retry never fired; it is covered by tests against a fake Ollama. Thinking made Gemma several times slower and worse at this job, so it stays off.

The prompt needed real fixes. The first version returned valid JSON every time, and as a parent I would still have rejected half of it. Asked for "breakfast", it invented cereal. Asked to split tooth brushing because it is the hardest part, a bedtime run kept it as one two-minute step. So the prompt now says:

- Use only the actions and things the parent names. Do not invent foods,
  clothes or objects. If the parent says "breakfast", say "Eat your
  breakfast".
- If the parent says a part is hard or asks to split it, that part MUST become
  two or three separate steps. Brushing teeth becomes "top teeth" and then
  "bottom teeth", each its own timed step.

Brushing has been split in every run since. Two more fixes came from reading output the same way: one run said "eat your breakfast until done", and another made breakfast a two-minute timed step, which would have locked the button while he eats.

What did not work. In 3 of 8 morning runs that I read line by line, Gemma folded "shoes and jacket" into just "shoes". Four rounds of prompt changes fixed everything else I found, but not this. The screenshot below shows it happening again, unedited: step 5 has no jacket. This is why the parent reads every step before approving, and why I would not let a model talk to my son directly.

Small things that turned out to matter:

The hold button fires after 0.8 seconds, measured from timestamps, not animation frames. Quick taps do nothing, and letting go early drains the ring.
Step timers come from timestamps too, so a throttled tab stays correct. ?speed=20 in the address makes them twenty times faster, which is how the screen got tested without brushing anyone's teeth for a minute at a time.
Gemma once returned a colon as the "emoji" for both teeth steps, and my validator let it through: it only rejected letters and digits. Now any plain ASCII there is rejected and replaced with a star.
The first voice the app picked sounded robotic. It now uses only voices installed on the device, never a network one: Premium first, then Enhanced, then a short list of natural voices, and never the novelty voices macOS ships. On the parent screen I can pick another voice and test it.
If I set a time to leave, the last screen says how long is left: "You have 14 minutes to play before liftoff."

What I cut. A speed comparison with the smaller gemma4:e2b. It was not on the laptop, so I have no numbers for it. It was one evening, and the kid screen got the time.

What is not tested yet. It has run in a browser in tablet mode on my laptop, not on a real tablet, and not with the person it is for. Speech voices differ between devices: for a natural one on a Mac or iPad, you download a Premium or Enhanced English voice in Settings > Accessibility > Spoken Content (Read & Speak on newer macOS), and the app picks it by itself. I expect the timers to need tuning once a real six-year-old is holding the button.

Why Does Open Innovation Matter?

For this project it is not a nice extra. It decides whether I would use the thing at all.

The input is a description of where my child struggles. "Brushing teeth is the hardest part." "He only eats one thing for breakfast." That is what I type into the box. With open weights on my own laptop, those sentences go from my keyboard to my own memory and nowhere else. I did not have to read anyone's privacy policy to decide that this was fine.

It does not need the internet. The page, the Lexend font, the model and the saved missions all live on the laptop. A morning routine should not depend on somebody else's uptime.

It costs nothing, so I can be picky. I generated dozens of missions while tuning the prompt. There is no meter running, no key to protect, and no account to create for a tool that a six-year-old uses.

Anyone can change how it thinks. The system prompt is a text file in the repository, and the model is one line of configuration. If your kid is four, or ten, or needs steps cut even smaller, you edit a paragraph of English, not a product.

A hosted API would probably have written similar JSON. But I would be sending notes about my son to a third party every time, paying per call for something that runs a few seconds a week, and tying his morning to a service that can change or disappear. The weights are a file on my disk, and the whole point of this tool is that every day looks the same. For a family tool, local and open is simply the right shape.

Prize Categories

Best Use of Gemma. Gemma 4 runs locally through Ollama and writes every mission. It is used with schema-constrained output, a validation and retry loop, and a system prompt written for one specific job: turning a parent's description into single, physical, kid-sized steps.

Side Project Graveyard: a proper burial for dead repos

Nazar Boyko — Sun, 04 Oct 2026 17:27:41 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

I have a folder of side projects that stopped at some point and never really came back. Some of them were useful for a while. Some made it into production. Some survived for two days, got a README, and then spent the next three years pretending they were merely "paused".

So instead of deleting them, I built them a cemetery. 😂😂😂

Each project gets a stone: its years, an epitaph, a cause of death, the stack, the last commit message, and the one thing it taught me. You can walk the yard, hover a cause of death to see which graves it took, read an obituary, and light a candle.

No stone has its own artwork. A stone's height comes from how long the project lived, its moss and cracks from how long ago it died, its marks from the cause of death, its brass and flowers from being retired with honour. A two-day todo app is a low marker with a wooden tag. A framework that never had a user is a mausoleum.

The home page opens with a register: 14 buried, 3 retired with honour, average lifespan 355 days, most common cause of death "Lost interest". Nobody typed those numbers. A grave points to its cause and its stack as Sanity documents, and Astro counts them during the build.

There are 18 graves. Five are public repos of mine, written up from their GitHub metadata and READMEs. The other 13 are invented, and you have met them before: the todo app that lived two days, the framework with a router, an ORM and no users, the newsletter with one subscriber and a 100% open rate.

Demo

Live site: side-project-graveyard.boyko-nazar.workers.dev

Three clicks worth making:

The register on the home page, then hover "Lost interest" in the legend and watch the other graves step back.
Sunday Letter, the newsletter tool. Read the last line of the obituary.
The candle on any grave. It counts in your browser and nowhere else, and the page says so. Go back to the yard afterwards: that grave is lit there too.

The animated tour at the top is a Playwright recording of the live site, converted to a GIF with ffmpeg.

Code

nazboyko / side-project-graveyard

Side Project Graveyard

Every repo deserves a proper burial.

I have a folder of side projects that stopped. This site gives each of them a stone: an epitaph, a cause of death, the stack it was built with, its last commit message, and the one thing it taught me. The content lives in Sanity, the site is Astro, and I built it for the DEV × Sanity Challenge by prompting Claude Code.

Live site: https://side-project-graveyard.boyko-nazar.workers.dev
Studio: https://side-project-graveyard.sanity.studio
Sanity project ID 20pcz8by, dataset production (public)
Build log, with every prompt and every failure: docs/BUILD_LOG.md

All six screenshots, at 1440, 768 and 390 pixels, are in docs/screenshots.

Content model

Four document types, defined in studio/schemaTypes/.

Type	What it is	Fields
`project`	A grave	name, slug, epitaph, status (buried, retired, undead), born and died dates, cause, stack, last commit, mood at death, lines of code, obituary, lesson, repository, and an

…

View on GitHub

studio/ is the Sanity Studio: four schema types, the desk structure, the seed content, the script that set the monument fields.
web/ is the Astro site: one file of GROQ queries, one file that turns a record into a monument, one of date and stats maths, all tested; five page templates; one stylesheet bundle; every drawing hand-written SVG; five generated images for the scene and the stone, in web/src/assets/scene/.
docs/DESIGN_BRIEF.md is the redesign plan, written from two outside reviews.
docs/visual-enhancement/ is the visual audit a second agent wrote before it touched the materials, and docs/image-prompts.md has the prompts for the five images.
docs/BUILD_LOG.md is the prompt log. Every prompt is in it word for word, and so is every failure.
CLAUDE.md holds the rules the session ran under.

My Build Process

I used two tools. Claude Code built the site and the redesign, in one session. Codex, a second agent, wrote a visual audit and implemented the material pass at the end. Claude Code then reviewed that pass and corrected it.

Before the session I wrote two things by hand. A plan: the concept, the schema, and one prompt for each of eight phases. And a rules file: one phase is one branch and one pull request, merge when CI is green, write every prompt and every failure into the build log, stop only when a step needs my browser. Then I typed one kickoff prompt and the model read the phase prompts from the plan.

The numbers: 16 pull requests, and CI never failed on one of them. The build took 8 phases and about 95 minutes of the model's work; the first five phases, from a bare Studio scaffold to 42 built pages, took 52. Then the session waited seven hours for me to click through a hosting dashboard. The redesign took five more pull requests and about 65 minutes, with two stops for my review. The material pass was one pull request by the second agent, and the review of it took Claude Code 66 minutes. A final check before publishing found twelve dependencies without a credit in the README; that fix was the sixteenth pull request. 25 messages from me in all.

The parts worth telling are the ones where the prompt and the result disagreed.

My kickoff was wrong in three places. It said my global git excludes would hide the tooling folder. They did not. It assumed a git identity existed on the machine. None did. It asked for a job-level if: hashFiles(...) in the CI workflow, which GitHub Actions does not allow. The model caught all three before anything failed: it ran git check-ignore before staging, looked up the author on my earlier public repos before the first commit, and moved the condition to the steps. The build log lists them under "what failed", because my prompt failed, even if no command did.

The schema got its real test from a broken file. The prompt asked for a date rule: a death date is required unless the project is undead, and it cannot come before the birth date. The model wrote 17 validation rules with messages in the voice of the graveyard keeper. Then it could not check them on screen, because the Studio stops at a login and it does not sign in to my accounts. So it wrote three broken graves into a file and ran sanity documents validate on it. Seven errors came back, among them "A project cannot die before it is born." and "Only the undead may go without a date of death."

astro add installed React into a site with a no-React rule. npx astro add @sanity/astro added react, react-dom, sanity and styled-components as direct dependencies. They are peers of the integration, for an embedded Studio this site does not have. The model removed them and tried to keep them off disk with legacy-peer-deps. That broke astro check, which then printed a misleading request to install @astrojs/check, a package that was already there. The cause was a pruned peer of an unrelated package. The model found it by importing the package by hand, dropped the setting, and let npm install the peers. Same phase: npm installed TypeScript 7, astro check wants 6. Three retries in 13 minutes, all in the log.

The screenshots looked right and the page was wrong. After building the pages the model took screenshots at three widths and they were fine. Then it read the text of the links in the browser and found "Previous graveEverything.js" and "Lost interest5graves". Two spans sat side by side with no space between them, so a screen reader would have read them as one word. No screenshot shows that. Lighthouse came out at 100 in all four categories after the fix, and I trust the number more because of what was found before it.

The plan said Cloudflare Pages. The dashboard gave me a Worker. "Connect to Git" now creates a Worker with static assets, built by Workers Builds. My plan, my rules file and the README the model had drafted all said Pages. I also told the model to continue before the hosting existed and gave it the URL I expected to get. It did not take my word for it. The name did not resolve, there was no .env, sanity hooks list was empty. It deployed the Studio, wrote the webhook test script, and stopped again with that evidence. When I came back with the real URL, the fix was an 11-line wrangler.jsonc and a reworded README. A publish in the Studio now reaches the live site within a minute. I measured it with a script that stamps the footer line and polls the page.

The review changed the order of the graves. The first version listed the newest death first. That put my five real repos in the top rows, with sober one-liners from their READMEs, and pushed the better epitaphs below the fold. The review phase flagged it. The graves are now ordered oldest first, which is how a cemetery grows: the old part is by the gate.

The redesign started from a working site that looked like a dashboard. Five tiles, a row of pills, eighteen identical cards. I had two outside design reviews done, and one of them proposed a map in TypeScript with a visual entry per project. That would have put content in code and broken for the next grave. The brief I wrote instead had one rule: the stone is computed from the record. The model added one field to the cause (motif) and one optional group to the grave (monument: shape, relic, inscription, figures), set them with one script, and wrote describeMonument(project, now), which knows no grave by name. A test runs it on the seed file and checks the brief's own counts: 4 ancient stones, 6 aged, 2 settled, 5 fresh, 1 disturbed.

The model was not allowed to ship anything it had not seen. Every visual branch went through at least three rounds of screenshots at three widths, and the model read every image. 19 drawings were redone because of what it saw. The sky had no warm band. The fence strip read as a barcode. Moss looked like polka dots. The smallest stone floated in the sky above the fence because the candle button was pinned to the ground instead of the stone. A shovel pushed a marker off its tag. Signpost, briefcase and crates were brown on brown ground and disappeared. None of these would have shown in a type check.

A second agent added the photographs, and the first one reviewed its work. The redesign was drawn in CSS and SVG and still looked flat. I generated five images in ChatGPT (image model Sol 5.6, effort set to medium, two candidates per image, and I kept the one with the better detail and the right amount of objects in the frame): a wide dusk cemetery, a portrait version for phones, a limestone tile, a soil tile and a strip of grass. Codex wrote an audit of the site first, then put the photographs behind the gate and the limestone on the stones, in one pull request, and reported Lighthouse accessibility 100. Claude Code reviewed that pull request from its own screenshots. It measured the pixels behind the tagline and got 2.65:1. Lighthouse cannot measure text over an image, so the 100 had not covered it. It also blocked the image to test the fallback and found half of the old fence in the dark, found a pale gate post floating in the sky of every grave page, and found that one of its own relics from the day before had been lying across "lived less than a day" the whole time, in a screenshot it had committed itself. Eleven fixes went in. Firefox would not start for the model on my machine, so I opened the preview in Firefox myself, and the log says the check was mine. The last fix came after that: the relics had always had an ink outline in Safari and none in Chrome, and now they are flat in both.

One of the six repos I had named as real graves turned out to be private. The prompt said to skip it in that case, and the model did. For the five real ones it left "mood at death" and "lines of code" empty. Its note in the log: they would have been guesses.

What I cut and why

A form where visitors bury their own projects. It needs accounts or moderation, and neither fits a weekend.
A candle count shared between visitors. It needs a write path, and the dataset is read-only from the site on purpose. The count is local and the page says so.
The Studio embedded in the Astro site. It needs server output, and this site is static files.
A library of photographed stones. The brief planned cutouts for every shape. Five generated images replaced it: two for the scene, three as materials. The stone shapes are still CSS masks, the words on them are still HTML, and the relics are still hand-written SVG.
A backdrop I can change from the Studio. The field exists and works, but one wide image cropped for a phone is not the portrait image, so it stays empty and the two local images are the default.
A gate that swings open on scroll, leaves, fireflies, a crow. One fog band and one cat stayed.
Every animation except the candle, the undead grave's light, the fog and a 3-pixel lift on hover.
The App SDK and Workflows bonus. I wanted one path done well.

What I would do differently

I would check the hosting dashboard before writing the plan. Seven hours of this build were me finding out that a product had been renamed.

I would also give the model a way to see the Studio. It tested the schema well without it, but I am the only one who has looked at the desk.

Sanity Project Details

Project ID: 20pcz8by
Dataset: production (public)
Studio: https://side-project-graveyard.sanity.studio
Schema: studio/schemaTypes/. Four types: project, cause, tech, siteSettings. The grave has an optional Monument group; the cause has a required mark.
Seed content: studio/seed/graveyard.ndjson, 41 documents.

The dataset answers without a token. This query returns each cause of death with its number of graves:

https://20pcz8by.api.sanity.io/v2026-09-01/data/query/production?query=*[_type=="cause"]{title,"graves":count(*[_type=="project"%26%26references(^._id)])}|order(graves desc)

The content model is small on purpose. Cause and stack are references, so the site can count them. The death date is validated against the birth date and the status. The epitaph is capped at 120 characters because that is what fits on the stone, the inscription at 28 ("The mason charges by the letter."), the figures at three ("A grave is not a dashboard."). The settings are one document that the Studio will not let you duplicate or delete.

Every part of a stone comes from these fields: height from the dates, weathering from the date of death, marks from the cause's motif, brass from the status, shape, relic and inscription from the optional monument. The cat sits on whichever grave was published last, so it moves when I publish.

Agent Session

The full agent transcript is not attached: it contains my local notes and paths that are not part of the project. Every prompt is in docs/BUILD_LOG.md instead, word for word: one entry per phase, with what came out, what failed, and what the model decided on its own. The material pass ran in a Codex session, and its prompts are in the same log.

Seed content is a mix of five real dead projects of mine and 13 invented ones. The stats are computed from all of them at build time.

When to Stop Asking the AI to Fix Its Own Fix?

Nazar Boyko — Thu, 01 Oct 2026 04:34:23 +0000

A few weeks ago I ran into one of those bugs that looked simple enough that I kept thinking the next fix would probably solve it. A small Node.js and TypeScript service was pulling jobs from several APIs, normalizing them and storing them in PostgreSQL. The background worker finished without errors and logged that the import had completed successfully, but when I checked the database, some of the jobs simply weren't there.

Running the same import again would often make more of them appear. Not all of them, just more, which made the problem look like some kind of timing issue. So I asked the AI to take a look. 😎

The first suggestion was to add retries around the database writes. That seemed reasonable, but it didn't help. Then came a delay, changes to the transaction boundaries, a higher retry count and eventually some extra error handling around individual inserts. Four rounds later, the symptom was exactly the same, while the diff had spread through the worker, the database layer and the tests.

The actual bug turned out to be an async callback inside a forEach. None of the suggested fixes had touched it.

I don't think the AI was being dumb here. I think I kept handing it the same information and asking for a different answer.

Look at the symptom from the AI's side for a second. Rows go missing and a rerun brings more of them back and nothing in the description says where they went, so it smells like timing, right? Every fix it suggested followed that smell from the first round to the last.

First it added retries around the database writes. Then came a delay, different transaction boundaries and a higher retry count. By the last round, it was catching individual insert errors so one bad record wouldn't affect the rest of the batch.

Those guesses weren't unreasonable. If all you know is that some rows go missing and a rerun brings some of them back, a timing issue is an obvious place to look. I probably would have started there too. 🙄

The funny part is that there really was a timing problem, just not the one we were trying to fix. The writes weren't happening too early or taking too long. The worker simply wasn't waiting for them to finish.

And that's where the debugging nightmare really started, because by that point neither the AI nor I seemed to understand the problem any better than when we began. 😕 By the fourth attempt, the suggestions had started circling back to the same ideas, just with slightly different settings. The last one went in another direction, but it still didn't solve the problem. If an insert fails and the code catches the error and continues, the row is still missing; now the failure is just quieter.

Here's what I think was going on. Every round the AI got the same clues (some rows are missing and a rerun brings back more). Unless a model gets logs or a way to run things, it works from the description and the code it can see, and "still missing" adds nothing to either of those. So it guessed again from the same clues, except that now the conversation also held every guess that had already failed, and every new answer had to work on top of the code the previous answers had left behind in the worker and the database layer.

At some point I realized we weren't really debugging anymore. We were just generating new guesses from the same two facts: some rows were missing, and running the import again brought some of them back.

And every failed fix made the next round a little messier. Now the AI wasn't only looking at the original code. It was also looking at retries, delays and transaction changes that had been added during the previous attempts. The code was changing, but my understanding of the bug wasn't.

Could a better prompt have helped? Maybe, but I'm not sure what I could have put in it. Everything I knew was already in the conversation. I could rewrite "some rows are missing" five different ways, but it was still the same piece of information.

What I actually needed wasn't a better way to describe the symptom. I needed one new fact about what the program was doing.

The Fact Was In The Order Of The Logs

So I stopped asking for another fix, reverted the changes and went back to the worker as it was before all of this started. This time I followed a single import through the logs from beginning to end, including the database writes.

That showed something off right away, just from the order of the lines. The worker logged "completed" before all of the inserts had finished. A job can't be done while its own writes are still running, unless nobody's waiting for them.

Here's the shape of the code. On a quick read it looks fine:

jobs.forEach(async (job) => {
  await saveJob(job);
});

console.log("Import completed");

forEach calls the callback once per job and ignores whatever the callback returns. An async callback hands back a promise as soon as it reaches its first await, so forEach ends up with one promise per job, drops every one of them on the floor and returns as if the work were done. MDN says it plainly: forEach() "expects a synchronous function" and "does not wait for promises." So the log line runs while the inserts are still in flight and the job gets marked complete with its writes still going in the background, and by the time some of those writes failed the worker had already reported the whole import as a success.

I think that's also why a rerun kept bringing more rows in. Every run got a few more of the inserts through.

The fix is to give the code something to wait on:

await Promise.all(
  jobs.map((job) => saveJob(job))
);

console.log("Import completed");

Now the log line waits for every insert and if one of them fails Promise.all rejects and the code after it never gets to say "completed". It does start all the inserts at once, though, and MDN notes that a rejection "does not cancel the remaining operations", so after one failure the rest keep running. If you want the result of every insert, Promise.allSettled waits for all of them. And if parallel inserts aren't wanted at all, a plain loop does one at a time:

for (const job of jobs) {
  await saveJob(job);
}

console.log("Import completed");

It's slower, but nothing's running behind your back. (There's also a lint rule for this exact mistake. typescript-eslint's no-misused-promises flags an async callback passed to forEach and it's switched on in the recommended-type-checked config, so a type-aware lint setup would have pointed straight at it.)

Anyway, once I saw the order in the logs, finding the actual bug took a few minutes.

After Two Failed Fixes, I Go Find A Fact

My rule now: if two AI fixes fail and I still haven't learned anything new about the bug, I stop asking for another fix. First I find one new fact: a repro, an error, a payload, a stack trace or just the real order of events like this time. Then the AI comes back in, with that fact. Not before.

What made me stop this time was the diff, honestly. It had spread into the worker and the database code and the retries and the tests while the symptom stayed exactly where it was, and on top of that one of the new suggestions was just a variation of something it had already tried. Those two together are a pretty reliable sign that the guessing's run out. I'd add one more: a fix that swallows errors has stopped looking for the cause.

I'm not saying AI is bad at debugging. I still use it for this all the time. But if I'm on the third fix and I still haven't learned anything new about the bug, I've probably stopped debugging and started guessing.

That's what happened here. A fifth fix would have been working with the same information as the first four. The logs were the first thing that actually changed what I knew.

How many failed fixes do you usually let an AI try before you stop and go back to investigating the bug yourself?

The AI Writes Better React than Vue

Nazar Boyko — Tue, 29 Sep 2026 13:41:23 +0000

In May 2025 a team at ByteDance published Web-Bench, a coding benchmark with an unusual detail tucked into its appendix. It gives the same tasks to four UI frameworks (React, Vue, Angular and Svelte) and checks every result with end-to-end tests. The model that led their overall results was Claude 3.7 Sonnet. With thinking turned off it passed 65% of the tasks in React. In Vue it passed 30%.

I also tried testing this on two projects, and sure enough, the AI is better trained or, I would say, has a better understanding of React projects. 🤷

Here's the whole table from the paper's appendix. The numbers are pass rates in percent, measured as pass@2 over five runs:

Model	React	Vue	Angular	Svelte
Claude 3.7 Sonnet (thinking)	60	40	50	55
Claude 3.7 Sonnet	65	30	40	25
Doubao 1.5 Pro (thinking)	50	40	25	40
Doubao 1.5 Pro	35	35	5	10
GPT-4o	35	30	5	20
DeepSeek-R1	40	30	30	40

It's a small sample. Each framework gets one project of twenty tasks so five points is roughly one task. The ranking isn't clean either, and Svelte beat Vue for two of the six models even though far fewer people use it. But React came out at or above Vue for every model on the list. And the authors' first explanation is the one anyone would guess: React "provides the largest dataset for LLM training."

It matches what I see in my own work. React from an assistant usually reads like React somebody wrote this just recently, whereas in Vue, deviations are more common! And these deviations often look as if someone used a Vue 2 template that no longer exists, or mixed two API styles within a single component. Nothing dramatic. Just more to check.

So there's a criterion that has quietly slipped into framework choice, one nobody likes to say out loud: the AI is better at it. Is that a legitimate reason to pick a framework? Noooo... It's a legitimate input and a bad deciding factor. Here's how I get there. I'll start with the case for yes because it's stronger than the people who dislike the question want it to be.

The model has just read a lot more React

If we look at some basic statistics from GitHub, for example, we can see that the number of stars on GitHub hardly reflects this difference. The paper lists React at 235k and Vue at 208k but stars measure attention and a model learns from the code people actually write and publish, so usage is where the gap lives.

In the 2025 Stack Overflow survey 44.7% of respondents used React and 17.6% used Vue. On npm React got about 203 million downloads in the week of September 21 to 27, 2026 and Vue got about 18 million. That's the same roughly 11x gap that showed up when I compared the two frameworks.

Vue also carries a history problem that React mostly doesn't. Vue 2 shipped in September 2016 and was supported until the last day of 2023, while Vue 3 only came out in September 2020 and removed a handful of things Vue 2 code leaned on (the $on event methods, filters, $set), so for four full years almost every new Vue tutorial, answer and public repo on the internet was written for Vue 2, and some of what they taught doesn't work anymore.

Vue 3 also has two official ways to write a component. There's the Options API and there's the Composition API, and both are fully supported (the docs even point out that the Options API is built on top of the Composition API). So the model has three dialects of Vue in its training data. Mixing them is what I'd expect from a model that has seen all three used side by side for years. That's my reading, to be clear. The benchmark didn't test why.

React has old dialects too. Class components are all over public code and the React team only deprecated Create React App in February 2025. The difference is proportion, I think. There's so much hooks-era React out there that the current idiom usually wins.

The case for yes is real

In the same survey the most common frustration with AI tools was "AI solutions that are almost right, but not quite" and 66% of developers picked it. And 45.2% said debugging AI-generated code takes longer. That's why if a project has only recently been updated to Vue 3 but some components or services still use the Vue 2 approach, then each such instance requires a code review. Each one costs a read and a re-prompt, and across a team and a year that adds up to real hours.

Onboarding is the other half. Someone new to a React codebase who leans on an assistant gets taught current React. The same person on a Vue codebase can get taught a blend of Vue 2 and Vue 3 with no way to tell which parts are which. For a junior that can be worse than no help at all, because the old idiom arrives with exactly the same confidence as the current one and nothing in the diff or the passing test says which of the two they just learned.

Honestly, the mixed-style component is the sneakier problem. It usually runs fine. It just makes every later reader's job harder and it's the kind of thing that gets merged because it works.

So if a team is choosing between two frameworks it could live with equally well and it'll write most of its code with an assistant, I don't think it's silly to pick the one the assistant writes better, since that's a cost like any other and costs belong in a decision like this. If the argument stopped there I'd have nothing to add.

Choosing by corpus feeds the corpus

Here's where I get off. The first problem is that picking a framework because the model's read the most of it is a loop. The popular option gets more code written in it. The next models train on that code and get better at it, and that's what pushes more people toward it.

Lovable's one of the AI app builders, and in February 2025 it explained why it generates React. The reason it gave is the loop in one sentence: models trained on code "can generate high-quality React code due to its dominance in online resources." So the apps a tool like that produces are React, and some of those apps get pushed to public repositories, and public repositories are exactly what the next round of models reads when its makers go looking for code to learn from, and round it goes. I don't blame Lovable, it's a sensible product call. That's exactly why it's a loop and not a conspiracy (every single step in it is reasonable on its own, and I'd probably have made the same call in their seat).

There's a second gear, and it's the one that worries me more. The public Q&A that taught models how people really use a framework is drying up. A study in PNAS Nexus found that activity on Stack Overflow dropped 25% within six months of ChatGPT's release, compared with Russian and Chinese Q&A sites where ChatGPT was hard to get. The authors' own conclusion is that "the decreased production of open data will limit the training of future models."

React built its mountain of public answers before that happened. The next framework has to build its pile in a world where people ask a chatbot instead of posting a question, and the chatbot answers in a private window, and nobody's around to write the better answer three comments down that the next model would've learned from. If everyone picks by corpus size, nothing new ever gets a corpus.

What I want is a Vue and a Svelte and whatever comes after them still pushing on React ten years from now, and a whole industry quietly picking by training data is how that stops happening.

Models change in months, frameworks stay for years

The second problem is timing. Look again at the model that led that benchmark. Its API name is claude-3-7-sonnet-20250219 and Anthropic's deprecation page lists it as retired on February 19, 2026. That's a year to the day after the date in its name. After that requests to it just fail.

Vue 2 got support from September 2016 to December 31, 2023. More than seven years. A framework picked this year will very likely still be in the codebase long after the models that made it look like the easy choice have been deprecated, retired and replaced a few times over, by which point the reason it was picked is one line in an old planning doc and the code is the only thing left.

The gap itself also moves, and the clearest sign of that comes from the React side. I use CLAUDE.md in my project, and it includes a block that next dev wrote on his own! And to be honest, I didn't even notice it! It opens with "This is NOT the Next.js you know" before warning the agent that APIs, conventions and file structure "may all differ from your training data" and telling it to read the docs bundled inside node_modules before it writes any code at all. Turns out even React's biggest framework tells the model not to trust what it learned, and that's the side with the biggest corpus. Vercel measured the fix too. In their evals the agent that had the version-matched Next.js docs in front of it hit a 100% pass rate against 79% for the best skill-based setup.

I'm not aware of a Vue measurement like that. There's a community project called vuejs-ai/skills, which calls itself an early experiment and lives outside the official Vue organization. Anyway, the point stands: a fluency gap is the kind of thing that can shrink in a release or two, and nobody revisits a framework choice that fast.

An input, not the decision

So I'd keep it on the list, just not at the top. The codebase that already exists comes first, then the team you have and the one you'll hire, then the meta-framework that fits the product. After that comes how well the assistants you use write it, as a real line in the cost column. Between two options that tie on everything else it's a fair tiebreaker.

And if the answer is Vue or Svelte or anything else with a smaller pile behind it, go in knowing the price. More review time per generated file. Output checked against the current docs, not the model's memory. Mixed API styles treated as a real review comment and not a nitpick. Putting the current docs in the model's context the way Next.js now does by default makes the gap smaller, though I'm not sure it ever gets to zero.

I'd still rather pay that in review hours than pick a framework for the one reason that'll be out of date first. If you've picked a stack partly because the assistant was better at it, I'd like to hear how that held up.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

React and Vue Are Turning Into the Same Framework

Nazar Boyko — Mon, 28 Sep 2026 14:26:49 +0000

Before diving into this article, I have to say that I haven't been a front-end developer for a very, very long time 😁 I just analyze architectures and enjoy listening to people who argue about what's best to use on the front end. So I might be wrong about some things. 🤷‍♂️🤷‍♂️🤷‍♂️ Please correct me if I'm wrong!

Recently, I came across a team that was rewriting a project from Vue to Ract, and their argument was that Vue runs slower. 😬 This made me wonder, why does Vue run slower? And it turned out that the Vue code had been generated but not optimized.

And while there were a lot of questions about the code generation itself in the Vue project, the team didn’t have any questions at all about the generated code in the React project because everything works well there. 🤔🤨 But I won’t go into that right now, I’d rather analyze everything in detail and describe it in another article.

I won't go into a detailed comparison either, since there's plenty of that online. I'll just list the three main popular aspects below. Some add a fourth about templates versus JSX. That one's taste, so I'll leave it alone.

	React	Vue
Virtual DOM	yes	yes
Memoization	by hand, with `memo`, `useMemo` and `useCallback`	automatic, through reactivity
What re-renders	the component and its children, unless you stop it	only what read the state that changed

Every row in that table is out of date or about to be. React now ships a compiler that writes the memoization for you, and Vue is finishing a compile mode that drops the virtual DOM for any component that opts in. The two of them started from opposite ends of the same old argument and ended up in roughly the same spot: a build step that works out what doesn't need to run.

That's why I think this is the first year the interesting React vs Vue question isn't a technical one. They aren't the same framework. There's a whole section below on where they still split, but the three talking points everyone reaches for are exactly the three that are dissolving.

React's Memoization Moved Into The Build

React's default is simple and a bit blunt. The memo docs say it in one line: "React normally re-renders a component whenever its parent re-renders." For years the fix was to tell React by hand what was safe to skip. Here's what that looks like in a small product list with a search box and rows you can pick:

ProductList.jsx (by hand, before the compiler)

import { memo, useCallback, useMemo, useState } from 'react'

const ProductRow = memo(function ProductRow({ product, onPick }) {
  return <li onClick={() => onPick(product.id)}>{product.name}</li>
})

export function ProductList({ products }) {
  const [query, setQuery] = useState('')
  const [picked, setPicked] = useState(null)

  const visible = useMemo(
    () => products.filter((p) => p.name.includes(query)),
    [products, query]
  )
  const onPick = useCallback((id) => setPicked(id), [])

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <p>Picked: {picked ?? 'nothing'}</p>
      <ul>
        {visible.map((p) => (
          <ProductRow key={p.id} product={p} onPick={onPick} />
        ))}
      </ul>
    </>
  )
}

There are three tools here and two of them only work as a pair. memo lets a row skip rendering when its props look the same as last time. useCallback keeps onPick the same function between renders. That part matters. A fresh function counts as a changed prop and quietly defeats the memo. Forget the useCallback and the memo still compiles, still passes review, still looks perfectly responsible in the diff. It just skips nothing. useMemo is the odd one out. It keeps the filter from running again when the only thing that changed is picked.

The React team was blunter about all this than I'd be, and in the React Labs post from February 2024 they wrote that "manual memoization is a compromise. It clutters up our code, is easy to get wrong, and requires extra work to keep up to date."

React Compiler 1.0 shipped in October 2025 and works with React 17 and up. For new code the release post recommends "relying on the compiler for memoization and using useMemo/useCallback where needed to achieve precise control." Expo has had it on by default since SDK 54. Next.js 16 made the reactCompiler option stable but left it off by default while the team gathers build performance data (they also warn that builds get slower with it on, since the compiler runs through Babel, and the Rust port that runs inside Turbopack only showed up in Next.js 16.3 in August 2026 as an experimental flag). So "React memoizes for you now" is true, with a footnote: on the most popular React framework, somebody still has to flip a switch first.

What matters for this comparison is the component with the compiler on, next to the Vue version of the same thing:

ProductList.jsx (with React Compiler)

import { useState } from 'react'

function ProductRow({ product, onPick }) {
  return <li onClick={() => onPick(product.id)}>{product.name}</li>
}

export function ProductList({ products }) {
  const [query, setQuery] = useState('')
  const [picked, setPicked] = useState(null)

  const visible = products.filter((p) => p.name.includes(query))
  const onPick = (id) => setPicked(id)

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <p>Picked: {picked ?? 'nothing'}</p>
      <ul>
        {visible.map((p) => (
          <ProductRow key={p.id} product={p} onPick={onPick} />
        ))}
      </ul>
    </>
  )
}

ProductList.vue

<script setup>
import { computed, ref } from 'vue'
import ProductRow from './ProductRow.vue'

const props = defineProps(['products'])
const query = ref('')
const picked = ref(null)

const visible = computed(() =>
  props.products.filter((p) => p.name.includes(query.value))
)
</script>

<template>
  <input v-model="query" />
  <p>Picked: {{ picked ?? 'nothing' }}</p>
  <ul>
    <ProductRow
      v-for="p in visible"
      :key="p.id"
      :product="p"
      @pick="picked = p.id"
    />
  </ul>
</template>

The React version's just the first one with every wrapper deleted. The Vue version never had wrappers to delete.

The Compiler Writes Your useCallback, Not Always Your useMemo

I ran that plain React file through babel-plugin-react-compiler 1.0.0, because I wanted to see what it actually produces rather than trust the diagrams, and the answer is a lot of bookkeeping: ProductList gets 21 cache slots, ProductRow gets 6 of its own, and every one of them is a plain array entry checked by an if. Here's the part of ProductList that matters, trimmed down:

ProductList.jsx after babel-plugin-react-compiler 1.0.0 (trimmed)

export function ProductList(t0) {
  const $ = _c(21);
  const {
    products
  } = t0;
  const [query, setQuery] = useState("");
  const [picked, setPicked] = useState(null);
  // ...
  if ($[0] !== picked || $[1] !== products || $[2] !== query) {
    // ...
    const visible = products.filter(t4);
    let t5;
    if ($[8] === Symbol.for("react.memo_cache_sentinel")) {
      t5 = id => setPicked(id);
      $[8] = t5;
    } else {
      t5 = $[8];
    }
    const onPick = t5;
    // ...
  }
  // ...
}

That Symbol.for("react.memo_cache_sentinel") check is the compiler's version of useCallback(fn, []). The first render stores the function in slot 8 and every render after that reads it back. Nobody wrote a dependency array.

The filter's where it gets interesting. My hand-written useMemo was keyed on products and query. The compiler put products.filter(...) inside a block that's also keyed on picked. So picking a row runs the filter again. With fifty products nobody will ever notice. If the filter were genuinely slow, this is the case the release post means when it says to keep useMemo for "precise control", because the compiler caches what flows into the output and its idea of a sensible cache boundary (one big block keyed on everything the JSX reads, as far as I can tell from this output) isn't always the one I'd have drawn by hand.

Vue Got The Same Result From Reactivity

None of this was ever a question in the Vue version. The reason is how Vue decides what to run. Its docs describe it plainly: "each component instance creates a reactive effect to render and update the DOM." The render reads query, picked and visible, Vue records those reads, and only a change to one of them re-runs this render. computed caches its value and only re-runs the filter when products or query changes, so picking a row doesn't re-filter and I never had to say so.

Children follow a matching rule. Vue's performance guide says "a child component only updates when at least one of its received props has changed."

Here's the detail I didn't know until I read the compiled output. In the normal virtual DOM build the inline @pick handler inside the v-for becomes a brand-new function on every render. That's exactly what useCallback exists to prevent in React. Vue doesn't care. The runtime function that decides whether a child updates is called shouldUpdateComponent, and in it a changed prop only counts if it isn't a declared event listener, so as long as ProductRow declares pick in defineEmits, a brand-new handler on every render doesn't make a single row update. React asked me to keep the function stable. Vue just stopped comparing it.

Vue isn't completely free either. "Never needed memoization" oversells it a little. The same performance guide has a section on props stability: pass activeId to every item in a list and every item updates when it changes, pass active (a boolean worked out in the parent) and only the items whose value actually flipped do. That's the same class of problem React's memo solves, except in Vue you fix it by shaping props instead of wrapping components.

Vue even has its own dependency array. v-memo, which arrived in 3.2, skips a whole subtree unless the values in its array change. The docs say it's "provided solely for micro optimizations in performance-critical scenarios and should be rarely needed." Rarely needed is the honest version of never.

Vue Is Compiling Its Virtual DOM Away

Vue's virtual DOM already isn't the purely runtime kind. The template compiler leaves hints for the runtime (patch flags that say which part of a node can change, cached static content, flattened blocks so the diff skips whatever can't change), and the Vue docs call this a "Compiler-Informed Virtual DOM" and contrast it with React's, where "the reconciliation algorithm cannot make any assumptions about the incoming virtual DOM tree."

Vapor Mode goes the rest of the way. A component that opts in compiles to direct DOM operations with no virtual DOM at all, and since this is the claim in here that's most likely to go stale, here's exactly where it stands:

Vapor first shipped in Vue 3.6.0-alpha.1 in July 2025.
The first beta landed in December 2025, with the team saying Vapor now had "feature parity with all stable features in Virtual DOM mode" (Suspense in a Vapor-only app being the exception).
3.6 went to release candidate in July 2026. The newest one as I write this is 3.6.0-rc.9, from September 18.
npm's latest tag for vue still points at 3.5.43. There's no stable Vue release with Vapor in it yet.

The RC release notes call Vapor "feature-complete" and "100% opt-in." For now they recommend it for two things: a performance-sensitive page inside an existing app or a small new app built entirely in Vapor. Opting in takes one attribute on the script tag, <script setup vapor>, and after that the only real decision is about the app: one created with createVaporApp() leaves the virtual DOM runtime out of the bundle entirely, while a normal createApp() app can mix Vapor components in through vaporInteropPlugin and keep everything else exactly as it was.

I compiled the Vue component from the tabs above with 3.6.0-rc.9 in both modes. The normal build returns a render function that builds vnodes, like Vue always has, while the Vapor build returns this:

ProductList.vue with script setup vapor, Vue 3.6.0-rc.9 (trimmed)

const t0 = _template("<input>")
const t1 = _template("<p> ")
const t2 = _template("<ul>")
// ...
  const n1 = t1()
  const x1 = _txt(n1)
  _renderEffect(() => _setText(x1, "Picked: " + _toDisplayString(picked.value ?? 'nothing')))
  // ...
  const n2 = _createFor(() => (visible.value), (_for_item0) => {
    const _on_pick = () => (picked.value = _for_item0.value.id)
    const n4 = _createComponent(ProductRow, {
      product: () => (_for_item0.value),
      onPick: () => _on_pick
    })
    return n4
  }, (p) => (p.id), 3 /* FAST_REMOVE, IS_COMPONENT */)

There's no render function here and no vnodes. The markup is turned into real DOM templates once and cloned from then on, the <p> gets exactly one _renderEffect, and when a row is picked that effect is the only thing in the whole component that runs: it sets the text of one text node, and that's it. Props go to the child as getter functions (product: () => (_for_item0.value)), so the child reads the current value itself instead of receiving a new props object. The component's setup runs once and never again. Turns out that's the Solid model, and Vue's own docs say so, describing Vapor as a "Solid-inspired compilation strategy."

The subset's real, though. Vapor components don't support the Options API, app.config.globalProperties or v-memo, and getCurrentInstance() returns null inside them, but the one I'd watch for in an existing app is events. Vapor delegates most listeners to document. The release notes spell out the catch: if any ancestor calls stopPropagation() "the delegated handler will not run." Mixing Vapor and virtual DOM components works for ordinary props, events and slots, but the notes still warn about "rough edges" with VDOM-based component libraries.

The Paths Met At The Compiler, Not At The Mental Model

Put the two compiled outputs side by side. The convergence is obvious. Both frameworks now ship a compiler that rewrites a component into code nobody would write by hand, and both compilers exist for the same reason: to skip work for things that didn't change.

The mechanism's where they still split, and honestly I think it's the most important difference left. React's compiled ProductList is still a function that runs on every single render and checks its 21 cache slots on the way through to reuse whatever it can, while Vapor's version runs once and then leaves individual DOM nodes to a handful of effects, so that component never renders a second time.

React chose that on purpose, and the same React Labs post from 2024 says so: "Our vision is for React to automatically re-render just the right parts of the UI when state changes, without compromising on React's core mental model." That core model is UI as a function of state, and signals would change it. The TC39 Signals proposal is still at Stage 1. Its README credits design input from the authors of thirteen named projects, Vue among them. React isn't one of them. Vue's docs say outright that "signals are the same kind of reactivity primitive as Vue refs." And 3.6 goes further: it rewrites the core of @vue/reactivity by porting alien-signals, a standalone signals library, for better speed and memory use, so a reactivity system that was always signal-shaped now literally has a port of one sitting at its center. (The state management landscape piece covers what signals look like when you add them to React from the outside.)

This one's the difference you feel every day, not just in benchmarks. In React I call setPicked(id) and the whole function runs again with new values and the props stay read-only snapshots the entire time, so what I reason about is renders, while in Vue I write picked.value = p.id and the state changes in place and whatever read it updates on its own. There I reason about dependencies. Someone fluent in one has to relearn habits in the other. No compiler touches that part.

The Server Moved Closer On Both Sides, Unevenly

The third shared direction is the server. It's the messiest one. React 19 made Server Components stable in December 2024, and in the Next.js App Router "layouts and pages are Server Components" by default, with 'use client' added only where a component needs state or event handlers. And there's nothing like that in Vue's core. Nuxt has server components: .server.vue files that render on the server as islands and add none of their code to the client bundle, but the Nuxt docs say they're "still marked experimental" and that on client-side navigation "each island on the destination page must be fetched from the server." That's a different shape from RSC, where server components are the default and a serialized payload carries the rendered server tree to the client. Nuxt's stronger server story is Nitro, the server engine that lets API routes live in the same project as the pages, and it's the part of Nuxt I'd point a React developer at first.

Moving work to the server isn't free on either side, and the Next.js 16.3 announcement says plainly that Server Components "made navigations feel slow." A big chunk of that release is tooling to fix it. So both camps agree the server should do more, they just don't agree on the unit: React made the component the unit of server work, while Nuxt works at the level of routes and server endpoints and keeps component islands experimental.

The Ecosystems Are Nowhere Near The Same Size

Here's the row that didn't converge at all. These are npm downloads for the week of September 20 to 26, 2026, pulled straight from the npm downloads API:

Package	Weekly downloads
`react`	203,498,378
`vue`	18,457,765
`next`	67,256,843
`nuxt`	2,364,072

Download counts measure installs, not people (every CI run counts, and so does every package that depends on these), but an 11x gap between the libraries and a 28x gap between the meta-frameworks isn't noise, and Stack Overflow's 2025 survey points the same way from the people side: 44.7% of respondents used React and 17.6% used Vue, 20.8% used Next.js and 4% used Nuxt.

One number from that same week made me look twice. babel-plugin-react-compiler got 17.8 million downloads, nearly as many as vue itself. That's not a typo. A big part of that is Expo. Its Babel preset depends on the plugin because Expo turns the compiler on by default, and babel-preset-expo alone got 10.9 million downloads in the same week. Still. A React build plugin now gets installed about as often as the entire Vue framework.

None of that makes Vue small. Eighteen million installs a week is a very alive framework. But size is what decides how easy hiring is and how many libraries work on day one and how many answers already exist for your strange edge case, and React has a lot more of it.

Where I'd Actually Make The Call

Okay, but Vapor benchmarks alongside Solid and Svelte 5. Isn't that exactly the kind of performance gap a React compiler can't close?

It's a real gap in the benchmark. I won't argue that. The Vue team cites the js-framework-benchmark for that claim, and a compiled React component that still re-runs on every render isn't going to match one that never re-runs. It just doesn't decide the choice for most products. Vapor is still a release candidate, it's opt-in per component, it supports a subset of Vue, and the Vue team itself recommends it for one hot page or a small new app. And in my view the diff is rarely what makes a product feel slow anyway (the network and the amount of JavaScript shipped usually are), so if one screen really is diff-bound that's a reason to try Vapor on that one screen and not a reason to pick a whole framework.

So here's how I'd choose, in order.

The codebase you already have. If there's a working React or Vue app, keep it. In 2026 a rewrite from one to the other buys almost nothing on performance. Turning on the React Compiler is far cheaper than a migration. So is trying Vapor on the one slow page.

The team you have and the one you'll hire. A team that knows Vue deeply will ship better Vue than it'd ship average React, and the reverse holds too. When people switch, it's the mental model from earlier that costs them. The APIs are the easy part. If you're hiring a lot, the survey numbers are the honest tiebreaker: the React pool is about two and a half times bigger.

The meta-framework that fits the product. This is the one I'd spend the most time on. It now decides more of the architecture than the UI library does. Next.js if the product wants server components as the default and the team is ready for the server and client boundary and its caching model. Nuxt if the product wants a full-stack Vue app with server routes next to the pages and a more gradual path to the server. Most of the differences between React and Vue that still matter in 2026 live one layer up, in these two.

If your team already knows one of them well, that's your answer. It probably always was, we just had more interesting things to argue about.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

Laravel Is Not As Heavy As You Think

Nazar Boyko — Tue, 22 Sep 2026 13:25:12 +0000

Recently I came across another discussion about Laravel's memory usage and I can't say that it was exactly new to me, I've worked with Laravel and Lumen for years and have seen how differently they can behave in terms of memory, but it made me curious about what actually creates that difference. Is Laravel itself really that expensive, is Lumen significantly lighter because of the framework, or are we mostly looking at the effects of PHP configuration, OPcache, bootstrapping, and the way the application loads data? 🤷‍♂️

So I decided to measure it properly and break down where the memory actually goes. The result was not what I expected.

A hello-world route in a fresh Laravel 13 app peaks approximately at 0.66MB of PHP memory. The framework's share of that is 316KB. That's everything that runs before my controller method does. Ten thousand Eloquent models loaded in the same app cost 17MB. I went in expecting the ratio to go the other way because the number everyone quotes for a Laravel request is "20MB, maybe 30" and the framework gets the blame for it.

And it turns out that this number is also accurate! It’s simply the value you get when OPcache is disabled, and OPcache is off in exactly the places people measure, which is php artisan tinker and the test suite and the dev container, so the number travels from there into the pm.max_children calculation and the memory_limit argument and the "Laravel is heavy" thread, and nobody checks it again. So this piece is the two numbers side by side, then a walk through the knobs everyone reaches for with a before and after for each (php artisan optimize, the Composer class map, deferred providers, OPcache itself), then the one thing that actually moved the number by a lot. Which was how the models got loaded.

The setup first so the numbers mean something. Laravel 13.31.0 on PHP 8.4.22, in the official php:8.4-fpm-alpine image on an Apple silicon Mac, with MySQL 8.4.11 in a second container, and every request going through real PHP-FPM, a static pool with a single worker, with cgi-fcgi sending the requests so nothing else touches the process. Every number below is the third request to a route, so the worker's warm and OPcache has compiled everything it's going to compile. And MB in this article means 1,048,576 bytes because that's what memory_limit counts in.

The measuring code is small. Two constants at the top of public/index.php before the autoloader loads:

public/index.php

define('LARAVEL_START', microtime(true));
define('MEM_INDEX_START', memory_get_usage());
define('MEM_INDEX_START_REAL', memory_get_usage(true));

And a controller method that takes a reading on entry and does the route's work and returns every counter I could think of as JSON:

app/Http/Controllers/MeasureController.php

public function modelsGet(Request $request)
{
    $n = (int) $request->query('n', 10000);
    $entry = memory_get_usage();

    $items = Item::query()->where('id', '<=', $n)->orderBy('id')->get();

    return response()->json([
        'index_start' => MEM_INDEX_START,
        'route_entry' => $entry,
        'after_hydrate' => memory_get_usage(),
        'peak' => memory_get_peak_usage(),
        'peak_real' => memory_get_peak_usage(true),
        'count' => $items->count(),
    ]);
}

The worker's resident memory comes from reading VmRSS out of /proc/self/status in the same method, which I left out of the listing. The items table has 100,000 rows. Its eight columns are the kind a product table has: a SKU, a name, a 120-character description, a price, a quantity, a flag and the two timestamps. It's boring on purpose, because I wanted the shape of a product table rather than a benchmark table.

memory_get_usage(true) Counts 2MB Chunks, And A Warm Worker Starts With Several

Before any Laravel numbers I want the two functions straight. The gap between them confuses people and honestly I had to go read the allocator to be sure I understood it myself.

memory_get_usage() is what the script has allocated right now through PHP's allocator. memory_get_usage(true) is what that allocator has taken from the operating system whether the script is using it or not. The manual says the second one is "the value that memory_limit is enforced against" and adds that the amount the operating system has given the process is a different and typically much larger number. So there are three numbers, what you use, what the allocator holds and what the process holds, and this article is mostly about the first with a stop at each of the others.

The allocator is the Zend Memory Manager (Zend/zend_alloc.c in php-src). It asks the OS for memory in chunks of exactly 2 * 1024 * 1024 bytes, the ZEND_MM_CHUNK_SIZE constant in zend_alloc_sizes.h, and it hands 4KB pages out of those chunks to the script. That's why memory_get_usage(true) only ever returns multiples of 2,097,152. Never anything else. Every "real" figure in my results is one of those: 2,097,152 for the hello route and 20,971,520 for 10,000 models and 186,654,720 for 100,000. Anything bigger than a chunk minus one page is a "huge" allocation and gets its own mmap() call. So the very large numbers aren't rounded quite as coarsely.

Here's the part I didn't know. On the third request for 10,000 models the worker had just served the first two. memory_get_usage(true) at the very top of index.php said 14,680,064. Seven chunks before a single line of Laravel ran. After two requests of 100,000 models the same line said 136,314,880. That's sixty-five chunks. The allocator doesn't hand chunks back at the end of a request. In zend_mm_shutdown it keeps a running average of how many chunks each request peaked at, holds that many in a cache for the next one, and resets the real counter to (cached_chunks_count + 1) * ZEND_MM_CHUNK_SIZE, so on a worker that has seen a heavy request the real number starts high and stays high for a while, even for a hello world, until enough small requests pull the average back down. That's not a leak, it's the allocator guessing that the next request will look like the last few.

Two practical consequences. memory_limit is enforced against the chunk count. A script whose memory_get_usage() never reached 128MB can still die with "Allowed memory size of 134217728 bytes exhausted", because the chunks behind it got there first. And if you log memory_get_peak_usage(true) from a long-lived worker as the cost of a request you're partly logging the previous request. For per-request work the non-real peak is the honest one. Since PHP 8.2 there's also memory_reset_peak_usage() for the Octane and queue-worker case where the process never ends.

Without OPcache The Bootstrap Is 15MB. With It, 316KB

Now Laravel. Same hello route and same worker in two configurations, and that's the whole experiment. The first is what laravel new leaves you with when OPcache isn't on: no config cache and no route cache and the plain PSR-4 autoloader. The second is what a deploy script should leave you with: php artisan optimize plus an optimized class map plus OPcache on.

Checkpoint	OPcache off, no caches	OPcache on, caches on
top of index.php	385,200	339,640
after vendor/autoload.php	2,007,888	360,608
after bootstrap/app.php	3,285,760	418,152
controller method entry	15,773,808	663,096
peak for the whole request	17,827,888	691,216
files included	460	400
classes declared	444	410
wall time	28.3ms	0.8ms

Bootstrap here means the difference between the top of index.php and the first line of the controller, and it's 15,388,608 bytes in the first column and 323,456 in the second. 14.7MB against 316KB for the same framework and the same 400-odd files and the same providers registered and booted. The 47x difference is where the compiled code lives.

This was one of those results where I reran the test a few times because the difference looked almost too large to be real. 😁😁😁

Without OPcache every one of those 460 files is read, tokenized, parsed and compiled on every request, and the result (the opcodes, the class tables, the constant arrays, the interned strings) is allocated in the request's own heap through the same allocator memory_get_usage() watches, and that's the 15MB. Laravel isn't doing anything with it. It's the cost of holding the compiled form of Laravel in memory once per request per worker and throwing it away at the end.

With OPcache on the compiled form lives in a shared memory segment. PHP-FPM's master process maps it once and every worker uses it. opcache_get_status() on the same hello request reported 412 cached scripts using 22,686,344 bytes of that segment out of the default 128MB (opcache.memory_consumption=128). So the 15MB didn't disappear, it became 21.6MB that's paid once per server instead of once per request, and it stopped showing up in memory_get_usage() entirely because OPcache's segment isn't the request heap.

An honesty note, since this is the part where a cheaper per-request number gets sold as a cheaper server. The FPM worker's resident memory for the hello route was 27.7MB with OPcache off and 30.7MB with it on. That's higher, not lower. The worker now has the shared segment's touched pages mapped in as well as its own heap. What OPcache buys isn't a smaller process. It's a process that doesn't grow by 15MB of compiled framework every time a request starts, and a request that takes 0.8ms instead of 28.

'php artisan optimize' And The Class Map Barely Move The Number

This is the section I expected to be the meat of the article, and it turned out to be the footnote. Every deploy guide says to run php artisan optimize (config:cache and event:cache and route:cache and view:cache in one command) and composer install --optimize-autoloader. Both are right. Neither's about memory.

Peak memory of the hello route in all eight combinations:

Autoloader	artisan optimize	OPcache	Entry	Peak
PSR-4	no	off	15.04MB	17.00MB
PSR-4	yes	off	14.33MB	16.40MB
class map	yes	off	15.53MB	17.60MB
authoritative class map	yes	off	15.53MB	17.60MB
PSR-4	no	on	0.77MB	0.80MB
class map	no	on	0.77MB	0.80MB
PSR-4	yes	on	0.63MB	0.66MB
class map	yes	on	0.63MB	0.66MB

php artisan optimize is worth 0.7MB per request without OPcache and 143KB with it, and that's the whole effect. You can see the mechanism in the file count: 460 included files without the caches and 400 with them. The config cache replaces reading .env plus every file in config/ with one require of a 20KB bootstrap/cache/config.php. The route cache replaces routes/web.php and all the registration calls with a single cached file. Those are real savings in time and syscalls (the docs describe config:cache as reducing "the number of trips the framework must make to the filesystem"), and they're tiny in memory, because reading thirty small PHP files and reading one bigger one produce roughly the same arrays in the end.

The class map is the more interesting row because it goes the wrong way. composer dump-autoload -o turns the PSR-4 rules into a flat array of 6,861 class-to-file entries (this app has 8,090 PHP files under vendor/) and that array has to exist in memory to be useful. Without OPcache it's built on every request, the "after autoload" checkpoint went from 2,007,888 bytes to 3,272,056, and the whole request got 1.2MB more expensive. With OPcache the array is a literal in a compiled file and OPcache stores literal arrays immutably in the shared segment and the per-request cost of the map is zero. The --classmap-authoritative flag, the one that stops Composer from checking the filesystem for classes missing from the map, changed nothing I could measure either way. Which is fine, because Composer's own docs sell the class map as a speed feature ("should always be enabled in production") and speed is what it delivers: fewer file_exists calls per class rather than fewer bytes.

So both knobs are worth turning and both are for CPU and disk rather than memory.

Deferred Providers Save Nothing Unless register() Does Work

Deferred providers come up in every Laravel performance thread so I tested them too. The framework already does this for itself: the compiled manifest in bootstrap/cache/services.php for this app lists 31 providers (30 from the framework plus AppServiceProvider), and 16 of them are eager and 15 are deferred. The question was what deferring my own provider would save.

Four providers added one at a time to bootstrap/providers.php, measured on the hello route with everything else in the production configuration:

A normal provider: three singleton() bindings in register(), nothing in boot(). The kind you write for a payment gateway or a search client.
The same provider, deferred: implements DeferrableProvider, with provides() listing the three bindings.
A heavy provider: register() does require on a 527KB PHP file that returns a 5,000-entry lookup array and binds it as an instance. The anti-pattern where "registering" a service means building it.
The same heavy provider, deferred: the require moves inside the singleton closure, so it runs only when something resolves the service.

Extra bytes at controller entry compared with no extra provider at all:

Provider	OPcache off	OPcache on
normal, eager	+8,168	+2,456
normal, deferred	+384	+0
heavy, eager	+3,373,528	+184
heavy, deferred	+176	+0

The normal provider costs eight kilobytes when it's loaded on every request and nothing when it's deferred. Eight kilobytes, for the whole provider, on every request. That's one file compiled and one object constructed. It's exactly what the docs say deferring saves ("it is not loaded from the filesystem on every request") and it's no more than that. If the app has forty providers like that then deferring all of them is worth about 300KB without OPcache and about 100KB with it. Rendering one small Blade page added about 200KB in the same runs.

The heavy provider is the row worth staring at. Without OPcache it costs 3.4MB per request because the whole 5,000-entry array gets built from source each time and deferring it takes that to zero. With OPcache it costs 184 bytes per request even when eager, because the array is a literal in a compiled file and OPcache keeps it as an immutable array in the shared segment, and I checked this twice since I didn't believe it: the segment's used_memory grew by 1.3MB when that provider was added and the request heap didn't move. require on a file that returns a constant array is close to free under OPcache. require on a file that computes an array or reads JSON or hits the network is not, and deferring is the fix for that whether OPcache is on or off.

So deferring's a real tool with a narrow target: providers whose register() actually does work. Marking a provider that only binds closures as deferred is correct and clean, and it won't show up on any graph.

Ten Thousand Models Cost 17MB. A Hundred Thousand Don't Fit

Everything so far was fractions of a megabyte in the production configuration. Here's what the route that loads data did on the same worker with the same OPcache and caches:

Route (10,000 rows)	Entry	Peak	Peak, real	Time
`Item::query()->...->get()`	0.64MB	18.44MB	20.0MB	40ms
`DB::table('items')->...->get()`	0.64MB	14.15MB	16.0MB	9ms
`->chunk(1000, fn)`	0.64MB	2.58MB	6.0MB	52ms
`->lazy(1000)`	0.64MB	4.25MB	6.0MB	52ms
`->cursor()`	0.64MB	3.17MB	4.0MB	122ms
`->cursor()`, unbuffered query	0.68MB	0.88MB	2.0MB	119ms

Ten thousand Eloquent models are 17,991,000 bytes on top of the entry point, which is 1,799 bytes per model for a row with eight columns. The same ten thousand rows through the query builder, as plain stdClass objects with no Eloquent around them, are 11,717,416 bytes or 1,172 per row, so the row itself (the strings and the numbers and the object that holds them) is about two thirds of the cost and Eloquent's $attributes array plus the $original copy it keeps for dirty checking plus the model object itself is the other third. Neither number is surprising once you know every PHP value carries a header and every array slot costs more than the value inside it. I think, the point is the ratio between them. One get() on ten thousand rows is fifty-five times the whole framework bootstrap and it's a line most codebases have somewhere, behind an export or a report or an admin page nobody paginated.

At 100,000 rows the get() route peaked at 183,961,728 bytes. That's 175MB, with the worker's resident memory at 208MB. Under the default memory_limit=128M it doesn't get that far:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
  in /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 442

Then a second fatal 65,536 bytes later in ClassLoader.php, while Laravel tried to autoload the exception handler to report the first one, so the client got a 500 with an empty body, nothing reached laravel.log, and the only evidence of what happened was in the FPM error log.

The 50,000-row version fit at 88MB, and somewhere between those two numbers is the export that works in staging and dies on the first real customer. The fix isn't a bigger limit, it's the other four rows of the table, and they aren't equal.

chunk(1000) peaks at 2.58MB and stays there whether the table has 10,000 rows or 100,000 (2.65MB at 100k). It runs one LIMIT 1000 OFFSET n query per page, hands the page to the callback, and then (this is in BuildsQueries::chunk) calls unset($results) before fetching the next page, so there's one page in memory at a time, and the price is a hundred queries for a hundred thousand rows, 1,088ms in total against 407ms for the single get().

lazy(1000) peaks at 4.25MB. Higher than chunk, and I think that's because of how the generator's written. The loop is $results = $this->offset($offset)->limit($limit)->get() followed by a yield per row, so when page two is fetched page one is still sitting in $results until the assignment completes, which puts two pages at the peak instead of one, and it's still flat (4.32MB at 100k) and it's still the one I'd pick for a foreach, because 1.7MB isn't a reason to prefer chunk's callback style over a plain loop.

cursor() is the one people get wrong. I'd got it wrong too before I ran this. It runs a single query and yields one hydrated model at a time so it looks like it should be the smallest of the lot, and at 10,000 rows it's 3.17MB, and at 100,000 rows it's 24.28MB and climbing with the table. The Laravel docs say why in a sentence that's easy to skim past: it "will still eventually run out of memory" because of "PHP's PDO driver internally caching all raw query results in its buffer". A MySQL query is buffered by default, so mysqlnd pulls the entire result set into the PHP process before the loop sees the first row, and with mysqlnd that buffer counts against memory_limit. So cursor() saves you the hydrated models and nothing else. It doesn't save you the rows.

The last row of the table shows what happens when the buffer goes away. I set PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to false on the connection before the same cursor() call and the 100,000-row loop peaked at 920,976 bytes. That's under a megabyte for the whole table in a single query. The manual's caveat is that an unbuffered result set owns the connection until it's fully read, so any query inside the loop on the same connection fails, and Laravel's own docs point you at lazy() instead for that reason, and I'd agree with them for anything that touches the database inside the loop. For a pure read-and-stream job an unbuffered cursor is the smallest thing PHP can do with a result set and honestly it's underused.

One more data point, because it changes the advice depending on the database. I repeated the cursor run against SQLite (a fresh Laravel install ships with it) and cursor() over 100,000 rows peaked at 847,088 bytes. The SQLite driver steps through rows as you ask for them with no client-side buffer. So the "cursor runs out of memory" warning's a MySQL fact rather than a PHP fact.

Okay, But My FPM Workers Show 35MB Each

That's the fair objection, and it's what makes people distrust the 0.66MB figure. ps on a production box shows php-fpm: pool www processes at 35MB and 60MB and 90MB and none of them are loading ten thousand models.

They're not lying, and neither is memory_get_peak_usage(), they're counting different things. Here's the same worker from the outside in three states with OPcache on:

Worker state	RSS
serving the hello route (measured inside the request)	30.7MB
serving the 10,000-model `get()` (inside the request)	52.1MB
idle, after the 10,000-model request has finished	36.3MB

The 30MB floor is the PHP binary and its extensions, plus the pages of the OPcache segment this worker has touched (shared with every other worker, but RSS counts them in each), plus the allocator's first chunk, and the 21MB on top of that during the model request is the heap from the previous section, and the 36MB after the request has finished is the allocator's chunk cache from two sections ago, the worker keeping some of the chunks it peaked at so that a worker that's served one heavy request stays bigger than one that hasn't until enough small requests pull the average back down. Multiply that by a pool where every worker eventually gets one heavy request and you've got the thing everyone observes on a dashboard, FPM memory that only goes up, with no leak anywhere in it.

Which is exactly why pm.max_children shouldn't be sized from memory_limit. The limit is a ceiling on one request's heap rather than a prediction of it, and dividing the box's RAM by 128MB gives you a pool less than half the size it could be for an app whose heaviest route peaks at 20MB. The manual describes pm.max_children as "the limit on the number of simultaneous requests that will be served". So the number to divide by is what one worker occupies while serving the heaviest route it will actually see. For this app on this box that's 52MB (the 10,000-model route measured from inside), so a 2GB budget for PHP gives about 39 workers, and if some route loads 100,000 models then it's 208MB per worker and 9 workers, and the right move there is to fix that route rather than buy the RAM, because the route that needs 208MB today is the route that'll need 400MB when the table doubles.

What I'd Actually Do

Measure the peak per route in production and keep the numbers. The cheapest version is a terminable middleware that logs the peak after the response has gone out:

app/Http/Middleware/LogPeakMemory.php

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;

class LogPeakMemory
{
    public function handle(Request $request, Closure $next)
    {
        if (function_exists('memory_reset_peak_usage')) {
            memory_reset_peak_usage(); // PHP 8.2+, matters under Octane
        }

        return $next($request);
    }

    public function terminate(Request $request, $response): void
    {
        Log::info('peak', [
            'route' => $request->route()?->uri(),
            'peak_mb' => round(memory_get_peak_usage() / 1048576, 2),
        ]);
    }
}

Append it globally in bootstrap/app.php and after a day you've got a histogram per route instead of a guess, and the routes at the top of it will be hydration, not bootstrap, so fix those first: paginate the admin page, lazy() the export, unbuffer the streaming job, and stop calling ->get() on a query with no LIMIT in it, because every one of those is worth more than all four bootstrap knobs combined, by a factor I measured at fifty-five.

Then turn the bootstrap knobs anyway, for time rather than memory. And make sure OPcache is on in every environment where someone is going to read a memory number, so the number they read is the real one.

Then size the pool from the log, not from memory_limit. That's it.

Octane changes the accounting but not the conclusion. It boots the application once per worker and keeps it in memory, so the 316KB is paid once and the per-request cost is only what the route itself allocates. But the worker never exits, and that's the catch. The model that leaks a reference or the static array that grows keeps growing, which is why Octane recycles a worker every 500 requests by default and why the memory_reset_peak_usage() line above stops being optional. If the Go version of this exercise is more your thing, I did the same measurement for goroutine stacks in I Spawned 1000000 Goroutines. Here's Where 13 GB of RAM Went. The shape of the answer was the same there: the number everyone quotes is true, it's just not the number that gets you paged.

The interesting part for me wasn't finding one magic Laravel setting that suddenly fixed memory usage. It was almost the opposite! Most of the framework-level optimizations changed far less than I expected, while one ordinary database call could outweigh the entire bootstrap dozens of times over. By the end of the tests, the framework overhead was almost the least interesting number. What the request loaded mattered far more.

Laravel costs 316KB a request. Your rows cost whatever you ask for.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

A Million Go Map Entries Take 38MB, Not 16MB

Nazar Boyko — Wed, 16 Sep 2026 14:47:35 +0000

A few months ago, I noticed an issue with the internal structure of the new Go map—specifically regarding empty slots! So I decided to figure out why a map[int64]int64 theoretically appears to be 16 bytes per element: 8 bytes for the key + 8 bytes for the value. But in Go 1.27.1, 1,000,000 elements take up approximately 37.8 MB, which is ~37.8 bytes per element. This made me wonder: where do those extra ~22 MB come from?! 🤔 And if you thought that Go simply adds some large header to each element, that’s not the case at all!

A Go map holding one int64 key and one int64 value takes 192 bytes of heap. A map[int64]int64 with a million entries takes 37.8MB. The napkin math for that second map is eight bytes of key plus eight bytes of value, sixteen bytes an entry, 16MB for the million and the gap between that and what the heap reports is what this whole piece is about. 🤷‍♂️

It's a follow-up to the goroutine stacks piece and it uses the same method, which boils down to taking something everybody in Go uses without thinking, making a lot of it and forcing a garbage collection to see what the runtime says is still live. The goroutine number held up until the goroutines called something. For maps it doesn't hold up at all. The cost per entry swings between 21 and 44 bytes depending on nothing but how many entries there are, and sets and deletes both behave differently on the current map than most of what's written about them says.

Everything below ran on Go 1.27.1 on an Apple M5 Max and I reran the byte counts on 1.26.4, which gave the same numbers apart from a little run-to-run noise right where tables split. MB means a million bytes throughout, since that's the unit the napkin math uses.

The Map Most Go Articles Describe Was Replaced In Go 1.24

Search for how Go maps work and most of what comes back is about buckets. A bucket holds up to 8 key/value pairs plus a few high bits of each key's hash, a ninth key that lands in a full bucket gets chained onto an overflow bucket, and once buckets average 6.5 entries the whole map doubles. Every bit of that was true, and it still sits in runtime/map.go in Go 1.23. There's a comment in there worth remembering. It says the bucket keeps all its keys together and all its values together because alternating them would need padding for something like map[int64]int8.

Go 1.24 replaced it with a map that doesn't have buckets at all. Go 1.24's release notes list "a new builtin map implementation based on Swiss Tables" among the runtime changes that cut CPU overhead by 2 to 3% on average, and Michael Pratt's post on the Go blog shows microbenchmarks where map operations got up to 60% faster than in 1.23. There aren't any overflow chains in the new map and there's no 6.5 either, so plenty of good writing about Go map memory describes a map that hasn't been the default since February 2025.

One Entry Costs 192 Bytes, A Million Cost 37.8MB

Here's the part of the harness that does the measuring. It reads HeapAlloc after a forced GC, fills the maps and reads it again after another one.

main.go

func liveHeap() uint64 {
    runtime.GC()
    var ms runtime.MemStats
    runtime.ReadMemStats(&ms)
    return ms.HeapAlloc
}

// bytesPerMap fills `copies` maps with n entries each and returns the live
// heap bytes per map. The keys exist before the first reading, so only the
// maps themselves are counted.
func bytesPerMap[K comparable, V any](n, copies int, keys []K, val V) float64 {
    maps := make([]map[K]V, copies)
    before := liveHeap()
    for c := range maps {
        m := make(map[K]V)
        for i := range n {
            m[keys[i]] = val
        }
        maps[c] = m
    }
    after := liveHeap()
    runtime.KeepAlive(maps)
    runtime.KeepAlive(keys) // or the GC can free the keys and subtract them
    return float64(after-before) / float64(copies)
}

Four details keep the numbers honest. runtime.GC() doesn't return until the collection and the sweep after it are done, so HeapAlloc right after it is live memory and not garbage waiting to be swept. Small maps get built many times over (as many copies as fit in two million entries) so a stray runtime allocation can't pass for a per-map cost. And the maps escape into a slice on purpose. A small map that provably never escapes can get its storage on the stack where HeapAlloc wouldn't ever see it. The last one's the KeepAlive(keys) line: a trimmed copy of this function that didn't have it reported 29.8 bytes per entry at a million, because when the call's the last place the keys slice gets used the second GC frees its 8MB and takes it off the total.

Here's map[int64]int64 at a handful of sizes.

# go1.27.1 darwin/arm64
     entries      bytes/map  bytes/entry
           1            192        192.0
           8            192         24.0
           9            376         41.8
          14            376         26.9
          15            664         44.3
         100           2392         23.9
         896          18519         20.7
         897          36991         41.2
        1000          36991         37.0
       10000         295585         29.6
      100000        2364444         23.6
     1000000       37812804         37.8
    10000000      302642440         30.3

One entry is 192 bytes and so are eight. The ninth entry nearly doubles the map and the fifteenth nearly doubles it again. At 896 entries each one costs 20.7 bytes, the closest a map[int64]int64 got to sixteen in any of my runs. Entry 897 pushes it straight to 41.2, and from there it keeps bouncing between the two with 37.0 at a thousand, 29.6 at ten thousand, 23.6 at a hundred thousand and 37.8 at a million. The keys and values don't change between rows. Only the count does.

Most Of The Extra Bytes Are Empty Slots

The new map's entries live in groups. A group is 8 slots plus an 8-byte control word with one byte per slot, and each control byte says whether its slot is empty, deleted or full, with the low 7 bits of the key's hash packed into it when the slot is full. That's what lets a lookup check all eight bytes against the hash in one go and only compare the keys whose bits already match. For map[int64]int64 that's a 16-byte slot and a group of 8 + 8*16 = 136 bytes.

A map with 8 or fewer entries is one group and nothing else (the source calls this the small map optimization), and the allocator doesn't have a 136-byte size, it rounds up to its 144-byte size class, while the Map header next to it is another 48 bytes. That's the 192.

The ninth entry turns that group into a real table with 16 slots, and from then on a table grows when it's 7/8 full (maxAvgGroupLoad = 7 in group.go, next to a comment saying it's "the same load factor used by Abseil"). Growing means building a new table twice the size and moving every entry into it. Right after a grow the table's only 7/16 full and more than half of it is empty, then it fills back up to 7/8 before the next doubling, and that's the whole shape of the table above: the cost per entry falls as a table fills and jumps every time it doubles, all the way up to entry 897.

Tables don't keep doubling past 1024 slots. That limit is maxTableCapacity in table.go and the comment above it has a TODO that says "Completely made up value", which I think is the most honest line in the runtime. A full table that size splits into two new 1024-slot tables and a small directory in front of them picks the right table from the hash's top bits. The blog post gives the reason: Go wants every insert to have "an upper bound on the amount of growth work it must do", and moving 896 entries is a small fixed amount of work no matter how big the whole map gets.

That's where the size-class rounding shows up again. A 1024-slot table is 128 groups or 17408 bytes and the allocator rounds that up to its 18432-byte class, so a table that's exactly as full as it's allowed to be (896 entries) costs 20.6 bytes per entry before any headers and a table that just split costs twice that. And since the hash spreads keys evenly, every table fills at about the same speed and splits at about the same moment, so the sawtooth doesn't smooth out as the map grows and its teeth just get wider. Around 110 thousand entries the map cost 21.4 bytes per entry and around 120 thousand it cost 39.3, and a million entries sits just past the split at 917,504, so that's the whole reason it comes out at 37.8.

I know this chart looks a bit like a heartbeat monitor... I promise it’s actually Go map memory usage. 😄

So the sixteen bytes are in there. They're the slot. What the napkin math doesn't count is everything around the slot and the biggest part of that is plain emptiness, because in any map past eight entries somewhere between 12.5% and 56% of the slots are empty by design.

A 129-Byte Value Costs Less Than A 128-Byte One

Everything so far used int64 keys and int64 values, and since the slot's the thing that repeats, key and value sizes move the whole number. Here's the same million entries with different types.

Map type	Slot size in bytes	Bytes per entry
`map[int32]int32`	8	19.5
`map[int64]int64`	16	37.8
`map[int32]int64`	16	37.8
`map[string]int64`	24	55.8
`map[int64][64]byte`	72	167.8
`map[int64][128]byte`	136	301.8
`map[int64][129]byte`	16, value stored separately	181.8

A slot is the key followed by the value, padded out to the alignment of the bigger one, so map[int32]int64 costs exactly what map[int64]int64 costs because 4 bytes of each of its slots are padding. There's a TODO in table.go that admits it: interleaving keys and values is good for locality "but it comes at the expense of wasted space for some types". That's the same padding the old bucket comment was avoiding.

A string key's 16-byte header goes in the slot (a pointer and a length) and the characters live in their own allocation, and since my keys were built before the first reading the 55.8 is the map alone, so a real map[string]int64 pays that plus whatever its strings cost.

The last two rows are the ones that don't make sense at first. Keys and values bigger than 128 bytes don't go in the slot at all: MapMaxKeyBytes and MapMaxElemBytes are both 128 in internal/abi and anything bigger gets its own allocation with a pointer in the slot. A [129]byte value costs a 16-byte slot plus a 144-byte object and a [128]byte value costs a 136-byte slot, so on paper the inline one should win. Even with one table as full as it can get (896 entries) the two only tie at 164.7 bytes each, since the inline version's groups array is over 32KB and anything that big gets rounded up to whole 8KB pages. At a million entries it's the 128-byte map that's 120 bytes per entry bigger. Turns out that's the empty slots again. An inline value takes all of its bytes in every slot, the empty ones included, while an empty slot in the pointer version holds just 16 bytes of key and pointer.

I wouldn't reshape a struct around the 128-byte line. But it explains how a big map of 100-byte structs ends up so much fatter than expected, since those 100 bytes get paid in every empty slot too, and map[K]*V does by hand what the runtime does past 128 bytes at the price of a pointer the garbage collector has to follow.

A struct{} Set Costs Exactly What A bool Set Costs

The standard advice for a set in Go is map[string]struct{} because struct{} doesn't take any bytes and bool takes one. On Go 1.23 that advice was right, by a little: I built the same harness with Go 1.23.12 (the last release line where the bucket map was the default) and a million-entry map[int64]struct{} came out at 22.3 bytes per entry against 24.6 for map[int64]bool, and that's because the bucket kept its 8 values in their own array where 8 zero-size values take zero bytes.

Here's how sets look on the three layouts I could build, all at a million entries.

Map type	Go 1.23.12 (buckets)	Go 1.27.1	Go 1.27.1 with mapsplitgroup
`map[int64]struct{}`	22.3	37.8	21.1
`map[int64]bool`	24.6	37.8	21.1
`map[string]struct{}`	40.1	55.9	39.0
`map[string]bool`	42.3	55.8	39.1
`map[int64]int64`	40.2	37.8	37.8

On the current default map the two set types cost the same (the string rows wobble by 0.1 between runs, in both directions) and both cost a lot more than they did on 1.23. It's the slot again. The slot's a struct with the key first and the value last. The compiler's rule is that any non-empty struct ending in a zero-size field gets one extra byte of padding, so that a pointer to that last field can't point past the end of the object (that rule goes back to issue 9401 from 2014). Alignment then rounds that one byte up to eight, and a bool is also one byte that gets rounded up to the same eight.

Three weeks before 1.24 shipped Michael Pratt opened issue 71368 about exactly this: "With swissmaps in 1.24, a map[int64]struct{} requires 16 bytes of space per slot, rather than the expected 8 bytes." Someone in the thread asked whether map[X]bool was just as bad and got a one-line answer: "Yes, both now allocate exactly the same amount of memory."

One map size can flatter one layout because 1.23 and 1.27 double at different points, so I reran the sets at a hundred thousand and five million entries too. The int64 set on 1.27.1 was 1.5 to 1.7 times its 1.23 size at all three sizes, while map[int64]int64 and map[string]int64 came out smaller on the new layout at all three (40.2 against 37.8 in the last row). Slots that need padding are where it's gone backwards, and the issue calls a set "the most extreme case" of that.

There's a fix already. Jake Bailey's change lays out a group as all 8 keys followed by all 8 values (KKKKVVVV instead of KVKVKVKV) and it was merged in March as GOEXPERIMENT=mapsplitgroup, but Go 1.27 ships with it switched off, so the last column is 1.27.1 with it switched on. With it on, sets drop just below their 1.23 size and map[int32]int64 goes from 37.8 to 27.9 while map[int64]int64 doesn't move because it never had padding to lose. On August 24 Michael Pratt's own change turned it on by default on the development branch and closed the issue under the Go 1.28 milestone. Even with split groups struct{} and bool still tie, though. Eight bool values fit in the same 8 bytes the padding would've taken.

make(map, n) Makes The Map Faster, Not Smaller

Preallocating is the other standard advice and the natural guess is that it makes the map smaller too, since a map built to size doesn't have to overshoot. Here's the same set of sizes built both ways.

# go1.27.1 darwin/arm64
   entries  grown bytes/ent make(n) bytes/ent
       100             23.9             23.9
      1000             37.0             37.0
     10000             29.6             29.6
     50000             23.6             23.6
    100000             23.6             23.6
    500000             37.8             37.8
   1000000             37.8             37.8
  10000000             30.3             30.3

Same numbers. A size hint asks for enough slots to hold n entries at 7/8 load and rounds the table and directory sizes up to powers of two, and that lands on the same layout growth reaches anyway because all the tables split together. Across the full sweep the two only disagreed right at split points, and not always in the hint's favor: at 897 entries the hinted map was 31.2 bytes per entry against 41.2 for the grown one, but at about 1.9 million it was 39.3 against 37.8.

The hint's payoff is in the work of getting there. Here's the testing.B side of the measurement.

fill_test.go

package main

import (
    "strconv"
    "testing"
)

var sizes = []int{1_000, 100_000, 1_000_000}

var sink map[int64]int64

func BenchmarkFill(b *testing.B) {
    for _, n := range sizes {
        b.Run("grow/"+strconv.Itoa(n), func(b *testing.B) {
            b.ReportAllocs()
            for b.Loop() {
                m := make(map[int64]int64)
                for i := range n {
                    m[int64(i)] = int64(i)
                }
                sink = m
            }
        })
        b.Run("make_n/"+strconv.Itoa(n), func(b *testing.B) {
            b.ReportAllocs()
            for b.Loop() {
                m := make(map[int64]int64, n)
                for i := range n {
                    m[int64(i)] = int64(i)
                }
                sink = m
            }
        })
    }
}

go test -run '^$' -bench BenchmarkFill -benchmem -count 3

BenchmarkFill/grow/1000-18             40568         27625 ns/op       74456 B/op         22 allocs/op
BenchmarkFill/make_n/1000-18          193857          6219 ns/op       36992 B/op          6 allocs/op
BenchmarkFill/grow/100000-18             478       2472747 ns/op     4729552 B/op        532 allocs/op
BenchmarkFill/make_n/100000-18          1441        838571 ns/op     2364600 B/op        258 allocs/op
BenchmarkFill/grow/1000000-18             25      42785217 ns/op    75605811 B/op       8209 allocs/op
BenchmarkFill/make_n/1000000-18           38      30394810 ns/op    37832752 B/op       4098 allocs/op

That's the first of the three runs, the other two were within about 5%. The B/op column is the cross-check against the heap numbers, and it holds up: a preallocated thousand-entry map allocated 36992 bytes and HeapAlloc said exactly 36992 bytes were live, while at a million entries the preallocated map's live bytes and its B/op differ by 1.5KB out of 37.8MB. A growing map allocates almost exactly twice its final size because each doubling throws the previous table away. On time, the hint made filling a thousand entries 4.4 times faster and a hundred thousand 2.9 times faster, but a million only 1.4 times. I'd guess that at a million most of the time goes into writing 38MB of memory the process has never touched, which both versions pay for equally. I didn't profile it to check though.

Deleting Every Key Gives Back Zero Bytes

Go issue 20135 ("runtime: shrink map as elements are deleted") was opened in April 2017 and it's still open, but everything in its thread was written about the bucket map, so deletes were the part worth checking again on the new one. The steps are in the labels below, and every line was read after a forced GC and measured against the heap from before the map existed.

# go1.27.1 darwin/arm64
filled                             len=1000000  heap=   37798.2 KB
deleted every key                  len=0        heap=   37801.2 KB
refilled with new keys             len=1000000  heap=   37838.2 KB
clear(m)                           len=0        heap=   37838.2 KB
refilled, deleted 99%              len=10000    heap=   37838.3 KB
copied survivors to a new map      len=10000    heap=     301.2 KB
m = nil                            len=0        heap=       5.6 KB

Deleting a million keys didn't free a byte. clear(m) freed nothing either. The map that went from a million entries down to ten thousand still held 37.8MB, nearly 3.8KB for each entry left in it, and the only line that moved at all is the one where the ten thousand survivors went into a fresh map and the old one got dropped.

The source says the same thing and it doesn't need any measuring. Clear walks every table and marks every slot empty and right after that loop sits a comment that just says TODO: shrink directory?, while Delete marks a slot empty or leaves a tombstone if its group is full, and nothing in internal/runtime/maps hands a table back while the map's alive. The old for k := range m { delete(m, k) } loop compiles into the same runtime call as clear(m) too. Brad Fitzpatrick pointed out in the same issue that the compiler rewrites that loop into runtime.mapclear.

Okay, but doesn't the garbage collector clean up after a delete? It cleans up what the deleted entry pointed to, and that's it. Keith Randall spelled out the split in that thread back in 2020: "the space for the keys and values themselves won't be reclaimed, as that space is part of the buckets. Only the things referenced by the keys and values will be collected." Swap buckets for groups and it describes the new map just as well. When a session gets deleted from a map[string]*Session the Session and the key's characters can be collected (if nothing else points at them) but the 24-byte slot stays where it is.

The map doesn't keep growing forever, though. Deleted slots get reused, which the "refilled with new keys" line shows well enough: a million new keys went into the emptied map and the heap moved by 37KB. I also ran a sliding window of a hundred thousand live keys where every insert deletes the oldest key, kept it going for twenty million inserts, and watched the map go from 2.36MB to 4.73MB by the two-million mark and then sit there for the other eighteen million. So a map with steady turnover settles at about twice its freshly built size, and a map that was once big stays as big as it ever got.

Josh Bleecher Snyder's first comment on the issue in 2017 is still the whole workaround: "The only available workaround is to make a new map and copy in elements from the old." It's cheaper than it sounds as long as it isn't done after every single delete. Someone in the thread asked about copying to a new map after O(n) deletes and Keith Randall's reply was "That would work fine."

What I'd Change In Real Code

Sets first. I'd still write map[string]struct{} because it tells the next reader the values mean nothing, but on Go 1.24 through 1.27 it doesn't save a single byte over bool, and honestly I wouldn't flip a GOEXPERIMENT in production just to get the split layout early. When the keys are small integers from a dense range the map is the wrong shape anyway, and the difference isn't small: a bitset for a million possible IDs (make([]uint64, 15625)) was 128KB of heap, the same million as a map[int64]struct{} was 37.8MB, and a plain []int64 indexed by the key took 8.0MB.

I'd preallocate whenever the size is known up front. The map ends up the same size but it gets there 1.4 to 4.4 times faster with half the garbage, and garbage is GC work later.

After a big delete I'd rebuild the map. That means copying what's left into make(map[K]V, len(old)) and dropping the old one, since nothing else gives the memory back.

And I'd measure the maps in the real service before rewriting any of them. A heap profile works, with one detail worth knowing before opening it: for a map made without a size hint, pprof puts the memory on the line that inserts into the map and not on the make line, because the tables get allocated as the map grows. My million-entry set showed up as 36.06MB on its assignment line, so pprof's MB is 1024 times 1024 bytes so that's the same 37.8MB.

The map with one int64 in it is still my favorite number from all of this. Sixteen bytes of entry, 176 bytes of map.

I tried to break all of this down in as much detail as possible and verify the numbers along the way. That said, this goes pretty deep into Go’s runtime and memory layout, so I may have missed something or made a mistake in one of the calculations. 🙄 If you spot anything that looks wrong, I’d genuinely appreciate a correction.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

I Added One Key to a PHP Array. It Cost 25 MB of Memory

Nazar Boyko — Mon, 14 Sep 2026 13:05:40 +0000

I was recently refactoring some legacy PHP code and noticed that the same data array was being used in completely different ways! Radically different! After some analysis, I came to the conclusion that a PHP array can be a very efficient data structure as long as it remains a packed list, but as soon as it turns into a hash table, memory consumption skyrockets, and for large datasets, associative arrays often consume nearly twice as much memory as regular typed objects.

In this article, I want to explain why this happens and what conclusions I've reached, because as I was told in the PHP community, only God knows where the memory goes 😀

After doing some analysis, I found that a PHP array holding one million integers takes 16.8 MB on PHP 8.4. If you add a single-character key, it takes up 41.9 MB. That means a single key takes up 25 MB. 🤷‍♂️

I'd read that PHP arrays are hash tables so many times I'd stopped hearing it, it sits in the same drawer as "floats are inexact". So I ended up building arrays of a million elements and watching memory_get_usage() while I did things to them. I started with the case PHP optimizes, then the ways that optimization quietly goes away, then a million rows from a query with each row an associative array, because every codebase I've worked on holds its rows that way. The rows are where the real cost is and the fix turns out to be smaller than the problem.

Everything below ran on PHP 8.4.21 in the official php:8.4-cli Docker image on 64-bit Linux with memory_limit set to -1 so nothing died halfway and where the version matters I ran the same script on 8.1.34 too, because 8.2 changed one of these numbers a lot and I wanted the before as well as the after. The figures are deltas of memory_get_usage(). The PHP manual says those are rounded up to the allocator's granularity, so treat the last couple of digits as noise.

Sixteen bytes per integer, until you add one key

Here's the sample code I used; this code for measuring memory usage isn't complicated at all. You can try replicating it too! The measuring code is nothing clever. Build the array, subtract two calls to memory_get_usage(), divide by the count.

bench.php

<?php
declare(strict_types=1);

const N = 1_000_000;

function report(string $label, int $bytes, int $n): void
{
    printf("%-42s %14s bytes  %6.2f bytes/elem\n", $label, number_format($bytes), $bytes / $n);
}

$before = memory_get_usage();
$a = [];
for ($i = 0; $i < N; $i++) {
    $a[] = $i;
}
report('packed list, keys 0..N-1 in order', memory_get_usage() - $before, N);

$before = memory_get_usage();
$r = [];
for ($i = N - 1; $i >= 0; $i--) {
    $r[$i] = $i;
}
report('same keys, filled in reverse order', memory_get_usage() - $before, N);

The two loops use the same keys and the same values. One counts up and the other counts down.

PHP 8.4.21 (Linux)
packed list, keys 0..N-1 in order          16,781,392 bytes   16.78 bytes/elem
range(0, N-1)                              16,781,392 bytes   16.78 bytes/elem
same keys, filled in reverse order         41,943,120 bytes   41.94 bytes/elem
SplFixedArray of N ints                    16,003,192 bytes   16.00 bytes/elem

Two and a half times the memory for the same million integers, because I filled it backwards.

That's the whole article in one line, honestly. The rest is why. 😃

The first array is what the engine calls packed. The keys are 0 and 1 and 2 and so on in order, so PHP doesn't store them at all, each slot is one 16-byte zval and that's it. The reverse-filled array has the same keys but they arrived out of order, so it's a real hash table with keys and hashes and an index at about 40 bytes per slot.

Then the part that made me sit up. Take the packed million and give it one string key.

$a['x'] = 0;

after adding one string key to packed list    +25,161,728 bytes
after adding key -1 to packed list            +25,161,728 bytes
after unset of that string key                +25,161,728 bytes (nothing came back)

One key. Twenty-five megabytes. And as it turns out, removing the key does not undo this action, because nothing on the unset path converts a hash table back into a packed one (sort() does, as it happens, and array_values() builds a fresh packed array, but plain unset only frees the value and leaves the layout alone). A negative key does the same thing as a string key, and I'm not sure why that surprised me since as an unsigned value it's enormous, but it did.

A packed array is a flat zval array; a hash array is buckets plus an index

Every PHP array is a zend_array and the C code calls it HashTable too. It's 56 bytes on 64-bit. Most of it is bookkeeping (a refcount header and flags and the table size and the element count and the next free integer key and a destructor pointer) and then there's one pointer to the data, and that pointer is a union, and the union is the whole story:

Zend/zend_types.h (php-src, PHP-8.4 branch)

union {
    uint32_t     *arHash;
    Bucket       *arData;
    zval         *arPacked;
};

In hash mode the data block has two parts. In front sits the hash index, an array of uint32_t slots with twice as many slots as there are buckets (the mask is -(nTableSize + nTableSize)) so that's 8 bytes of index per bucket and behind it sit the buckets at 32 bytes each:

Zend/zend_types.h (php-src, PHP-8.4 branch, comments mine)

typedef struct _Bucket {
    zval              val;   /* 16 bytes: the value */
    zend_ulong        h;     /* 8 bytes: the integer key, or the string key's hash */
    zend_string      *key;   /* 8 bytes: NULL for integer keys */
} Bucket;

A lookup hashes the key and masks it into the index and reads a bucket number there and follows a next chain stored inside the zval if two keys collided. Iteration never touches the index, it walks the buckets front to back, and since buckets are appended in insertion order that's how foreach gives you insertion order for free.

So a hash slot costs 32 + 8 = 40 bytes. A million elements need a table of 1,048,576 slots (more on that in a second), and 40 times that is 80 bytes short of what the measurement says. That's the 56-byte struct plus 24 bytes the allocator keeps to track a block that big.

In packed mode there's no index (two placeholder slots and 8 bytes total) and the data is zval *arPacked, a bare C array of 16-byte values where the position is the key. Sixteen times the same table size lands about 4 KB under the measured 16.8 MB. It's the same accounting with a smaller slot.

Here's the thing I hadn't tracked: packed arrays only became this cheap in PHP 8.2. Before that they used the same 32-byte buckets as hash arrays and simply skipped the index, with h repeating the slot's position and key always NULL in every slot. That lasted until Dmitry Stogov's PR #7491 ("Use more compact representation for packed arrays") was merged in November 2021 and shipped in 8.2.0 in December 2022. It's an internals change, so the 8.2 UPGRADING notes don't mention it at all (I went looking). Here's the 8.1 run for the before:

PHP 8.1.34 (Linux)
packed list, keys 0..N-1 in order          33,558,608 bytes   33.56 bytes/elem
same keys, filled in reverse order         41,943,120 bytes   41.94 bytes/elem

Half the slot memory of every list in your application, from one release. Tideways company measured the same thing when 8.2 came out, on a 100,000-element list, and got 4.3 MB down to 2.3 MB. If you're still on 8.1 for some reason, this is a decent argument on its own.

The other rule that's worth knowing is growth. Table sizes are powers of two with a minimum of 8, and a full table doubles (nSize = ht->nTableSize + ht->nTableSize in zend_hash_do_resize) so one million elements live in a table of 1,048,576 slots. Which means:

packed list of 1,048,576 ints              16,781,448 bytes   16.00 bytes/elem
packed list of 1,048,577 ints              33,558,664 bytes   32.00 bytes/elem

One more element and twice the memory. And it doesn't go the other way. I unset 999,000 of the million and memory_get_usage() moved by exactly 0 bytes. The values were integers so there was nothing to free, and the table itself doesn't shrink. An array remembers the biggest it has ever been. In a queue worker that's one of the reasons memory only ever climbs, and long-running PHP processes goes through the rest of them.

The rules for staying packed are stricter than array_is_list()

The conversion logic lives in _zend_hash_index_add_or_update_i in Zend/zend_hash.c. For an array that's currently packed, an integer key goes through this sequence.

Key below the high-water mark, slot filled. Overwrite in place. Still packed.
Key below the high-water mark, slot is a hole. Convert to hash. The comment in the source reads /* we have to keep the order :( */, and that's the real reason for all of this. A PHP array promises to iterate in insertion order, a packed array can only express "ascending", so any insert that would break ascending order forces the full structure.
Key inside the current table size. Append, fill any gap with undefined slots, stay packed. Writing $a[0] = 'a'; $a[5] = 'b'; gives a packed array with four holes in it.
Key past the table but less than twice its size, table more than half full. Grow, stay packed.
Anything else, every string key, and any negative key (as an unsigned value it's enormous). Convert to hash.

Here are two arrays with the same two elements and a different order of arrival.

[0 => 'b', 1 => 'a'] built at runtime      216 bytes
[1 => 'a', 0 => 'b'] built at runtime      376 bytes

The one that costs 376 bytes is a hash table with eight buckets and sixteen index slots. For two values. The 216-byte one is eight zvals and nothing else. Both are the minimum table size.

The gotcha that actually bites is array_filter(). It preserves keys and everyone knows that because of the JSON symptom where a filtered list encodes as an object. The memory symptom isn't as loud. Filter a packed million down to the even numbers and the result gets built key by key (0 then 2 then 4 then 6) until key 8 arrives and doesn't fit in the initial table of 8 and also fails the "more than half full" test, at which point the new array converts to hash on its fifth element and stays there for the rest of its life.

array_filter keeping every other element   20,971,600 bytes   41.94 bytes/elem
array_values() of that result               8,392,784 bytes   16.79 bytes/elem
array_is_list(filtered) = false

Half the elements and more memory than the original packed million. array_values() fixes it at the cost of one copy, and I think that's always worth paying if the result is going to live for a while.

And array_is_list() checks keys and not layout. It arrived in 8.1 and I'd assumed it was the test for this. It answers "are the keys 0 to n-1 in order" and a hash table can satisfy that:

[1 => 'a', 0 => 'b']                       376 bytes   array_is_list = false
after unset($b[1])                         376 bytes   array_is_list = true

The same 376 bytes and the same hash layout, and now the function says it's a list. Before PHP 8.4 no userland call showed you the layout, and the only honest instrument was memory_get_usage(). Since 8.4 debug_zval_dump() prints packed next to a packed array, and for this one it prints nothing.

A copy costs nothing until the first write

The refcount lives in the zend_array header, not in the variable. $b = $a bumps it and points both variables at the same table, and passing an array into a function does the same. And I've seen a rule somewhere that says we are only permitted to modify structures that we exclusively own, which means that they must have a refcount of one. Otherwise the engine separates first, and separation means duplicating the table.

$copy = $a                                          0 bytes
$copy[] = 1 (first write)                  16,781,392 bytes

For an array of rows there's a detail that works in your favor. Separation copies the outer table and bumps the refcount on each row, it doesn't deep-copy the rows. Appending to a copy of a million-row array cost 16.8 MB (the outer packed table), and changing one field inside one row of that copy cost another 376 bytes for that single row's hash table. The engine copies exactly what you touched, one level at a time.

A million rows as arrays cost twice what the same rows as objects do

This is the part I actually wanted to know. Query results as associative arrays are the default in every PHP codebase I've seen (either fetchAll(PDO::FETCH_ASSOC) or a query builder that returns the same shape). I'd guess most of the arrays alive in a typical request are hash arrays for exactly that reason, they came out of a query or a JSON body with string keys. So the test is a million rows of five fields with the same values in every container.

final class Row
{
    public function __construct(
        public int $id,
        public string $name,
        public string $email,
        public bool $active,
        public float $balance,
    ) {}
}

// each shape, built a million times in a loop and kept in a list
$row = ['id' => $i, 'name' => "user$i", 'email' => "user$i@example.com", 'active' => true, 'balance' => 1.5];
$row = new Row($i, "user$i", "user$i@example.com", true, 1.5);
$row = [$i, "user$i", "user$i@example.com", true, 1.5];

Bytes per row for a million rows, including the two strings and the slot in the outer list:

Shape	PHP 8.4.21	PHP 8.1.34
Class with 5 declared typed properties	233	250
Same class, `readonly` properties	233	250
Packed list per row (the `FETCH_NUM` shape)	321	498
`SplFixedArray(5)` per row	323	324
Associative array per row (the `FETCH_ASSOC` shape)	481	498
`stdClass` per row (the `FETCH_OBJ` shape)	529	546

One thing about this table: all six shapes ran one after another in a single process, and that makes the object rows look a little cheaper than they are. Every object also takes an 8-byte entry in the engine's object store, which doubles when it fills up and never shrinks, and the later object runs reused the entries (and some other bookkeeping) the stdClass run had already paid for. Measured each in a fresh process, a class row is 241 bytes on 8.4 and 258 on 8.1, and a SplFixedArray(5) row is 340 on 8.4 and 341 on 8.1. The array rows and stdClass come out the same.

The two strings are the same in every row. "user123456" and "user123456@example.com" cost 40 and 48 bytes each: a 24-byte zend_string header plus the characters plus a terminator, rounded up to an allocator bin. The slot in the outer array is 16.78. Take those 105 bytes off and what's left is the container, which I also measured one row at a time to be sure:

assoc row, 5 string keys                   376 bytes
stdClass row, 5 dynamic properties         416 bytes
packed row, 5 values                       216 bytes
SplFixedArray(5) row                       176 bytes
object row, 5 declared properties          128 bytes

The 376 is the number from the previous section: a 56-byte header plus a hash block sized for the minimum of 8 buckets (8 x 32 for the buckets and 16 x 4 for the index), which comes to 320 bytes. For five fields. Every row carries its own index, its own copy of the key hashes and pointers, and three empty buckets.

The object is 128 because a zend_object header is 40 bytes and declared properties are stored inline right after it at one 16-byte zval each (so 40 + 5 x 16 = 120 and then the allocator rounds that up to its 128 bin). The property names aren't in the object at all, because the class holds one table that maps each name to a slot offset (built once at compile time) and every instance is just the slots.

Typed or untyped and readonly or not makes no difference to the bytes. The type lives in the class and the slot is a zval either way, so the readonly DTO you'd write for correctness reasons is also the cheapest way to hold a row.

stdClass is the worst of both. It has the 40-byte object header and no declared properties, so every field goes into the object's own properties hash table, and that table is exactly the 376-byte array from before with an object wrapped around it. FETCH_OBJ gives you exactly this shape a million times over. PHP 8.2 deprecated dynamic properties on ordinary classes but the RFC marks stdClass with #[AllowDynamicProperties], so it isn't going anywhere.

The packed list per row is a nice illustration of the 8.2 change. On 8.4 it's 216 bytes: a header plus eight 16-byte slots rounded into the 160 bin. On 8.1 it's 376, identical to the associative version, because packed buckets were 32 bytes back then and eight of them plus the tiny index landed in the same 320-byte bin. So FETCH_NUM saved nothing at all before 8.2 and now it saves a third and costs you the column names.

Okay, but the driver hands me arrays. Turning a million of them into objects is a million constructor calls. Yes, and the constructor's cheap next to the query you already paid for. PDO can instantiate a class per row with FETCH_CLASS (though it assigns properties before calling the constructor unless you add FETCH_PROPS_LATE, and that makes constructor promotion awkward enough that I'd rather write the one mapping line myself anyway) but the better answer to "a million constructor calls" is that you shouldn't be holding a million of anything, and that's the last section.

SplFixedArray wins on flat lists, and ext-ds doesn't change the picture

SplFixedArray is a C struct with a zend_long size and a zval *elements buffer allocated at exactly size times sizeof(zval). There's no hash and no index and no power-of-two rounding. A million integers cost 16.00 bytes per element exactly against the packed array's 16.78 (the packed array rounded its table up to the next power of two). That 5% is the entire memory win, and in exchange you give up growth, string keys and every array_* function. For a five-field row it's 176 bytes (an object header plus the struct plus a separate 80-byte element buffer), and that's more than the class.

ext-ds (the PHP extension) I actually compiled for this, because it's the thing people bring up whenever PHP data structures come up, with one note before the numbers: pecl install ds gave me 2.0.0, and on this build it declared Ds\Seq, Ds\Map, Ds\Set, Ds\Heap and Ds\Pair and no Ds\Vector at all, so the numbers below are from 1.6.0.

PHP 8.4.21, ext-ds 1.6.0
Ds\Vector of N ints (push)                 16,085,160 bytes   16.09 bytes/elem
Ds\Map of N ints (reverse order)           37,748,960 bytes   37.75 bytes/elem
Ds\Map per row inside a Ds\Vector         512,457,608 bytes  512.46 bytes/row

Ds\Vector is a contiguous buffer whose capacity isn't tied to powers of two (the manual says so) so it lands at 16.09 instead of 16.78. Ds\Map beats the hash array by about 10%. A Ds\Map per row is worse than the plain associative array. It's a good API with real algorithmic guarantees and it does give memory back when a structure shrinks (which arrays never do). It isn't a memory fix for rows, and I wouldn't add a C extension to a deployment for 4% on lists.

What I'd actually do

Keep lists packed. Append in order, don't fill by index backwards, don't let a string key into something that's supposed to be a list, and call array_values() on anything that came out of array_filter() if it's going to live longer than the next line, and remember that array_is_list() is a fine assertion in a test as long as you know it's checking keys.

Rows you hold in memory go into a small final class with promoted typed properties. Half the memory of the associative array, a name and a type for every field, and readonly costs nothing extra. That's the one change I'd make to most of the code I've read that does fetchAll() and then walks the result.

And don't hold a million rows. Here's the materialize-then-loop shape against the same loop over a generator, run in two separate processes so the peak is honest, and the rows are generated in code with no database involved, so it measures the cost of holding them and not of fetching them:

function rows(int $n): Generator
{
    for ($i = 0; $i < $n; $i++) {
        yield new Row($i, "user$i", "user$i@example.com", true, 1.5);
    }
}

function loadAll(int $n): array
{
    $all = [];
    foreach (rows($n) as $row) {
        $all[] = $row;
    }
    return $all;
}

// materialize: foreach (loadAll(N) as $row) { $sum += $row->balance; }
// stream:      foreach (rows(N) as $row)    { $sum += $row->balance; }

materialize all rows, then loop     peak over start   241,157,928 bytes
stream rows through a generator     peak over start        37,008 bytes

Thirty-seven kilobytes instead of 241 megabytes for the same loop over the same million rows. With a real statement the generator is a while ($r = $stmt->fetch()) that yields one Row per iteration. There's one caveat and it's a big one on MySQL: queries are buffered by default so the driver pulls the whole result set into PHP's memory before your first fetch(), and with mysqlnd that buffer counts against memory_limit. So a generator over a buffered result set streams the objects and still holds every raw row underneath. The fix is to set Pdo\Mysql::ATTR_USE_BUFFERED_QUERY to false for the big query (on 8.3 and older it's PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, which 8.5 deprecates) or to page it by primary key. Laravel's cursor() is this exact pattern with a nicer name.

Sixteen bytes a slot is a fair price for a list. What gets expensive is how quietly an array stops being one. 🙂

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

I Stopped Reviewing Code And Started Reviewing Agents

Nazar Boyko — Wed, 09 Sep 2026 13:46:40 +0000

I had an incident at work where an AI-powered agent made a change that passed CI and seemed entirely reasonable in the PR. The problem wasn’t just with the code—the issue was that we had never properly verified what the agent was actually allowed to do, which tools it could run, and where its authority ended. And to be honest, this incident completely changed my view of the review process!

I hadn't really thought about what the agent does behind the scenes. I mean, where exactly it sends the data or if it sends it at all. If a problem came up while checking the code or comparing something in the code, I’d report it as a bug with the agents and ask for it to be fixed! After the agents fixed the bug, I’d test it again and was satisfied with the result, but I didn’t notice what the agents were doing behind the scenes.

For most of us, code review means just one thing - someone reviews the changes in the code. One person made the changes, another reviewed them, and the reading was the control. Not the tests, not the linter, the reading.

That stopped being true on a lot of teams and I don't think most of them have said it out loud yet. Picture the pull request an agent opens a few hundred changed lines across a dozen files, a tidy description, green CI. The reviewer opens it and reads the description. Spot-checks the migration and the tests. Approves. Nobody read the few hundred lines. Nobody was ever going to.

What got reviewed in that PR wasn't the code. It was the agent. Which instructions it ran under and which tools it had. What it was allowed to touch. Whether a human stood between its output and production. Whether the team admits it or not, that's where the review moved. This is about that move, why I think it's the right one, and why it's more dangerous than it looks.

Nobody is reading all of it

The diff-based review rested on an assumption so old nobody stated it: writing code is slower than reading it. One person produces a couple of hundred lines in a day and a colleague can read them carefully in twenty minutes, and that ratio held for decades, through every language and framework change, and it's the entire reason "read the diff" worked as a control.

An agent produces a day's worth of diff in under an hour and a team can run several of them at once. Reading didn't get any faster. So the ratio flipped. The control stopped holding on its own.

What happens next is the pattern that shows up on almost every team that adopted agents seriously. Review turns into skim. The reviewer reads the PR description (written by the agent), checks that CI is green (on tests written by the agent, against a spec the agent summarized from the ticket it was handed), scrolls past the longest file because it's mostly generated boilerplate and approves. It looks like review. It's a signature.

I'm not saying that to shame anyone, it's rational. Reading every generated line is not a strategy that scales and pretending it is just means the skim happens in secret. The honest version is to admit the line-by-line read is gone for most changes and ask what replaced it.

The review moved without anyone deciding it would

Here's what replaced it, though nobody wrote a policy. When a team can't inspect every output, it starts inspecting the thing that makes outputs. Nothing new there, it's how anyone hires a contractor. Nobody stands behind an electrician checking every wire nut. They check the license and which walls the electrician is allowed to open and that an inspector signs off before the drywall goes back up. Process trust in place of keystroke trust.

With agents the process is unusually concrete because most of it is config. Here's the shape of the actual review target on a project running Claude Code (the rule syntax is from the permissions docs; the specific rules are a made-up example):

.claude/settings.json

{
  "permissions": {
    "allow": ["Read(src/**)", "Edit(src/**)", "Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Bash(rm *)", "Bash(curl *)"]
  }
}

That file says more about what the agent can do to a codebase than any single PR it opens. Rules are evaluated deny first, then ask, then allow. The first match wins. So a broad deny can't carry an allowlist exception. Bash(npm run *) matches npm run test --watch and doesn't match npm install.

The file is meant to be checked into version control and shared with the whole team so it shows up in git as a diff. And in my experience it gets about the same attention as a .prettierrc. That's the drift in one picture: the control moved into a config file and the review process didn't follow it there.

Honestly, I think this is the most useful reframe available right now. The agent's permissions file, its system prompt and its tool list are the code now, at least in the sense that matters for review: they're the artifacts whose contents decide what ends up in production next week while nobody is looking, and they deserve the slow read the diff used to get.

What reviewing the agent looks like on a Tuesday

Not a checklist. Three questions I'd want answered before I trusted a PR from an agent, and in practice they cover most of what matters.

What can it call. Every tool an agent can reach is a capability someone granted. A model with a shell plus a database client plus an outbound HTTP tool is a very different colleague from one that can only read files. The sneaky part is that tools arrive through config rather than through code, so they skip the review that code gets, and I wrote up the worst case of this in Your .mcp.json Is a Backdoor Nobody Reviewed: six lines of JSON that download and run a third party's program with your credentials, plus a tool list that lands in the model's context before anyone approves anything, all of it merged under a commit message like "wire up the agent". Reviewing the agent means reading that JSON the way a new dependency gets read because that's what it is.

What this might affect? Scope of application! Which paths, which branches, which environments. The Claude Code documentation contains an important caveat that, as it turns out, is of great significance: the read and edit restrictions apply to built-in file-handling tools and to file-handling commands that the agent recognizes in Bash, such as cat and sed. They don't apply to a Python or Node script the agent writes and then runs, because that script opens files by itself. For that the docs point at the OS-level sandbox, and that's a separate mechanism with its own config block and its own defaults. So a sentence like "it's denied from reading .env" is true only at the layer where somebody configured it, and the review has to ask which layer that is (and whether the agent can reach the other one by writing a five-line script, because usually it can).

Who sits between it and production. This is the one that saves a team when the first two fail. GitHub's coding agent is a decent reference for what a gate looks like. By default Actions workflows don't run when Copilot pushes to a pull request until a maintainer clicks "Approve and run workflows". If the repo requires approvals, the approval of the person who asked the agent for the change doesn't count toward the number. A second human has to look. That's a deliberate design choice.

It's also the part that got a little weaker on September 1, 2026 when GitHub shipped an opt-in preview in which Copilot code review can itself approve a pull request and have that approval count toward the required-approvals rule. It's off by default, admins gate it, file paths can be restricted and the approval is dismissed when new commits land, so I don't want to overstate it, but the direction is clear enough: the reviewer of the agent's output can now be another agent, and at that point the only human review left anywhere in the loop is the review of the setup.

Okay, but a good setup still produced the bug

That's the objection. And it's a valid one. Here's the compromise, to put it simply: when the check shifts from the diff to the agent, the team stops detecting this specific error. The off-by-one in the pagination, the migration that drops a column it should have renamed, the retry wrapped around a call that was never idempotent, the kind of thing a careful reviewer used to catch on a quiet Thursday afternoon with twenty minutes and a coffee, and a permissions file catches none of it. It bounds the blast radius, it doesn't touch correctness.

So the thing being bought is leverage. One review, a hundred PRs. And the thing being paid is the specific catch. That's a good trade only if the guardrails are real and "real" has a precise meaning here.

OWASP's entry on excessive agency puts it in one line I keep coming back to: implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not. A guardrail that lives in the prompt ("never touch production") is a suggestion. A guardrail that lives in a deny rule, a scoped token, or a branch protection is a control. Reviewing the agent means checking which kind is actually there because the prompt kind fails silently the first time someone pastes a clever issue title into the agent's context (and I'm not sure most teams have tried that against their own setup, for what it's worth it's a ten-minute experiment).

And the liability didn't move with the review. Whoever merged the PR owns what it does, legally and in the incident channel; I went through the legal half of that in AI and code ownership. Process trust doesn't transfer responsibility. It only changes where the attention goes.

The diff still matters, one level down

I'm not arguing for reading less code. I'm arguing about where the read sits. In the model that's forming, the diff read becomes a sample, not the gate. The migration gets read closely because the blast radius is a table. The forty renamed imports get skimmed because the worst case is a failed build, and the attention that used to go to line 312 of a generated file goes instead to the layer that decides what the next hundred PRs are able to do, meaning the tool list, the scope and the gate, in roughly that order of how often they turn out to be wrong.

If the agent's diff still needs a slow careful human read every time then the agent isn't saving anyone anything. 🤷‍♂️

What's uncomfortable is that most teams made this move already, by attrition rather than by decision, in the sense that the skim happened one PR at a time, the approvals kept coming because the builds stayed green, and the permissions file that now decides what the agent can do to the codebase never got a reviewer because it never looked like the kind of file that needed one. If the review moved up a level, the reviewers have to move with it. Otherwise nobody is reviewing anything and the green check is the only one who noticed.

The diff is still worth reading. The review that protects you now happens one level up.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

Has AI Made You A Lazier Developer? Be Honest.

Nazar Boyko — Tue, 08 Sep 2026 12:31:46 +0000

Haven't you ever wondered if this AI vibe coding has made us lazy? Who's been solving problems on LeetCode lately? 😅

I've noticed that accepting is easier than thinking, by a margin so small that no single accept feels like anything, and it adds up anyway. Part of why it's hard to notice is that it feels faster even when it isn't.

But I've come to think "lazy" is the right worry aimed at the wrong thing. There are two kinds of lazy and only one of them is a problem.

I'm going to go into a little background here, because I didn't come up with this, and I didn't reach this conclusion on my own.

Lazy is why we have compilers

Larry Wall, who created Perl, put laziness first on his list of the three great virtues of a programmer, and his definition is the whole argument: "the quality that makes you go to great effort to reduce overall energy expenditure." Great effort. Good lazy isn't the absence of work, it's work moved somewhere better, and it's more or less why compilers exist (somebody got tired of writing the same assembly by hand and decided, reasonably, that the machine could do that part) and why every abstraction we lean on all day is really someone's laziness done properly.

Handing that kind of toil to a model is nothing new. The config I've written a hundred times and the regex I could write but would rather not and the Dockerfile I could recite and the test scaffolding that comes out identical in every project I've ever started: I understand all of it and I'm simply declining to type it again and I feel no guilt about that whatsoever (honestly I'd be more worried about a developer who insisted on typing all of it out by hand in 2026, on principle, one character at a time, while the rest of the team went home). That's not skipping the thinking. That's skipping the typing after the thinking was already done.

The other kind skips the understanding

The second kind of lazy offloads the understanding itself. The model writes the thing and it runs and the tests are green and the PR gets merged and somewhere in that chain there's now a piece of code nobody on the team could explain or fix, and that's the kind that costs, not today but on the day it breaks and somebody on call opens the file at 2am and finds a function nobody can vouch for.

The smallest illustration I can think of, made up on purpose: say the model writes a regex that validates email addresses at sign-up. If I could have written it and chose not to, that's the first kind of lazy, and if I couldn't have and it's now the thing deciding who gets an account, that's the second kind, and it's the same regex on the same line of the same diff either way. The reviewer can't tell the difference and neither can CI. The only place the two kinds differ is inside my head.

Okay, but isn't this just the old Stack Overflow copy-paste problem with a faster clipboard? Mostly yes. And I think that's what makes it worse. Stack Overflow made me go find the answer and read a thread of strangers arguing about it (sometimes with the accepted answer being wrong and the better one three comments down with a tenth of the votes) and then adapt it to my code. The friction was doing quiet work. The suggestion just appears in my file already indented and nothing about it asks to be understood.

Could you rebuild it if it vanished?

I don't have a rulebook for this and I'm suspicious of anyone who does. What I have is one question. Take the last thing the model wrote for you and imagine the file is gone. I don't mean the exact characters, nobody remembers those. Could you sit down and produce something that does the job, and would you know why it works?

If yes, that was the good kind of lazy and it's worth keeping. If no, it doesn't matter how fast it shipped.

That's the honest answer to the title, at least for me. It depends on the week. Some weeks every accept is toil I understand. Other weeks I'm not sure, which is a polite way of saying no. The drift never announces itself. It just gets a little easier to press tab each time.

So I'm asking. I want the real answer, not the one that sounds good. What was the last thing AI wrote for you, and could you rebuild it tomorrow? 😃

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋