DEV Community: Naze Code

I measured the viral "talk like a caveman" token saver. A two-word prompt got most of it.

Naze Code — Fri, 16 Oct 2026 10:49:11 +0000

There is a repo doing the rounds called caveman. Its pitch, verbatim from its own GitHub description:

🪨 why use many token when few token do trick. Viral skill + proxy for coding agents that cuts 65% of tokens by talking like a caveman.

It's one of the most-starred repos on GitHub. The idea is funny enough that it spread on the joke alone, which is exactly why it's worth measuring rather than sharing.

So I did. I broke a real C# program, asked four versions of the same agent to fix it, counted every token with the project's own tokenizer, and then compiled every answer to check that shorter hadn't meant worse.

Three findings surprised me, and one of them isn't documented anywhere.

First: the headline number contradicts its own docs

The description says 65%, from talking like a caveman.

The project's documentation page says something different in its own subtitle:

Install the skill for shorter answers, or the CLI proxy to cut input tokens by 33.2%.

Those aren't the same claim. Caveman is actually two products:

A skill — writing rules that make the agent's answers shorter. It changes what the model says (output tokens).
A proxy — a local program that compresses files and tool output before the model reads them. It changes what the model sees (input tokens).

The 33.2% figure belongs to the proxy. The description credits the saving to "talking like a caveman," which is the skill. It's selling the wrong half of its own product.

To its credit, the docs are far more honest than the marketing — including this concession, which turned into my control test:

"be concise" already captures much of the gain.

Second: it is not a pile of prompt files

My assumption was that this was a clever paragraph in a markdown file that got lucky. I was wrong. Pulling the repo tree and grouping blobs by extension:

caveman repo: 1785 files, 21.2 MB total

Go  (proxy+engine)      640 files    6.6 MB   30.9%
JS / TS                 450 files    5.6 MB   26.5%
Python                  103 files    1.3 MB    6.3%
Markdown (all docs)     179 files    1.1 MB    5.2%

skills/  THE CAVEMAN     64 files    0.3 MB    1.3%

31% of it is Go — a real proxy and a real compression engine, 398 and 165 files respectively. The famous "talk like a caveman" instructions are 1.3% of the repository.

The meme is on the front door. The thing behind it is a compiler.

The test: a real bug, not a toy prompt

Token benchmarks are easy to fudge with soft questions, so I used a bug with a verifiable pass/fail. Here's a C# shopping cart that silently loses an item:

public class Product
{
    public string Sku { get; set; }
    public string Name { get; set; }

    public override bool Equals(object obj) =>
        obj is Product p && p.Sku == Sku;

    // the hash is built from a field anyone can change
    public override int GetHashCode() => Sku.GetHashCode();
}

var widget = new Product { Sku = "W-1", Name = "Widget" };
var cart = new Cart();
cart.Add(widget, 3);

// the warehouse renumbers the SKU, after it is already a key
widget.Sku = "W-1-NEW";

var found = cart.QuantityOf(widget);
Console.WriteLine(found == 3 ? "PASS" : $"FAIL: expected 3, got {found}");

FAIL: expected 3, got 0

A Dictionary hashes a key once, at insert. Mutating Sku afterwards changes what GetHashCode() returns, so the lookup probes a different bucket, finds nothing, and Equals is never even reached. The entry isn't gone — it's unreachable.

The prompt (276 tokens) was identical every time: explain the failure, return a corrected class. Four variants:

Variant	What it is
`plain`	no instruction
`"Be concise."`	two words, prepended
`/caveman`	the real skill rules, injected
`/ultracave`	its maximum-compression mode

Three runs each, tokens counted with o200k_base — the encoding caveman's own docs specify.

Result: the 65% is real, but it's a different mode

variant      r1    r2    r3     mean   vs plain
------------------------------------------------
plain        896   951   688    845       -
concise      541   669   598    603  -28.7%
caveman      475   577   395    482  -42.9%
ultracave    314   317   293    308  -63.6%

/ultracave hits −63.6%. So the headline number is achievable — but from the maximum compression mode, not the caveman voice the description advertises. The voice itself lands at about −43%.

And "Be concise." gets −28.7% for three tokens and zero installation.

I'm not the first person here: Max Taylor benchmarked caveman against "Be brief" across 24 prompts with a second model grading quality, and found the two-word prompt matched caveman on both tokens and quality. My results differ on /ultracave — in my runs it beat the two-word prompt clearly, in his it didn't — but we agree on the part that matters: most of this saving is free.

A detail nobody mentions: compression also cuts variance

Look at the spread. plain ranged 688–951 (±15%). /ultracave ranged 293–317 (±4%). The terse modes aren't just smaller, they're markedly more predictable — which matters more than the mean if you're budgeting a long agent run.

The skill is not free

Those rules have to be sent to the model every session. Measured with the same tokenizer:

  1158 tokens   skills/caveman/SKILL.md
   608 tokens   skills/ultracave/SKILL.md

It costs 1,158 tokens to teach a model to use fewer tokens.

Against the free two-word prompt, /caveman saves ~120 tokens per answer. So:

break-even vs "Be concise.":
  caveman     1158 / 120  ≈  10 answers
  ultracave    608 / 295  ≈   2 answers

/ultracave is the better deal on both axes — half the overhead, more than double the saving. The default mode needs about ten answers in a session before it's even.

One caveat the project raises itself: if those rules sit in a cached prompt prefix, the overhead amortises. They haven't measured that. Neither have I.

Proof: did the answers get worse?

This is the part most token benchmarks skip. Tokens saved are worthless if quality drops, so I extracted the corrected class from every answer, compiled it against the original Cart, and ran it.

All four compiled. All four printed PASS.

Here's /ultracave's entire answer — 11 lines, and correct:

public class Product
{
    public string Sku { get; init; }
    public string Name { get; set; }

    public override bool Equals(object obj) =>
        obj is Product p && string.Equals(p.Sku, Sku, StringComparison.Ordinal);

    public override int GetHashCode() =>
        Sku is null ? 0 : StringComparer.Ordinal.GetHashCode(Sku);
}

init makes the identity field immutable, so the line that caused the bug (widget.Sku = "W-1-NEW";) becomes a compile error instead of silent corruption. That's the right fix.

Nothing was lost by compressing. The /caveman answer even caught a second bug the plain answer never mentioned: Sku.GetHashCode() throws on a null SKU. Meanwhile plain opened with "Didn't get permission to probe for a .NET SDK…" — precisely the filler these rules delete.

The finding that isn't documented: it compresses shapes, not formats

Now the proxy — the part the description forgot to credit, and the part nobody shares.

One thing first: the npm package is only a front end. The compression engine is a separate signed binary. Running compress without it is honest about that:

{"bytes_in":3801,"bytes_out":3801,"ratio":0,
 "engine":"missing",
 "note":"caveman-engine not installed — 0% compression, input passed through unchanged."}

With the engine in place, I fed it four real files:

file                      type      before   after    saved
-------------------------------------------------------------
build.log  (.NET build)  code         945     945       0%
repo.json  (nested API)  json        1965    1965       0%
records.json (400 recs)  json       19994    2509    87.5%
export.csv (400 rows)    tabular     8409     314    96.3%

The docs advertise ~98–99% on "CSV, logs, YAML, test output, JSON." On real data:

Uniform tabular data: enormous. 96.3% on CSV, 87.5% on 400 JSON records. The claim holds for this shape.
A build log and a nested API response: exactly 0%.

And it wasn't misdetection — asking the engine directly, it correctly identified them as code and json. It simply has nothing to do with them.

The rule, which isn't in the README: it compresses shapes, not formats. Rows of repeating records collapse beautifully. Prose-like logs and deeply nested objects don't. If your agent's context is mostly build output and API responses, this part does close to nothing for you.

Lossy to the model, lossless on disk

Every compressed result carries a flag that looks alarming:

"method":"elision", "lossless_to_model":false

The model genuinely does not see the original — parts are removed. That would be disqualifying, except every compression returns a recovery handle. So I took it, asked for the original back, and compared:

46,886 bytes out, 46,886 bytes in, cmp = IDENTICAL

Byte-exact. Lossy to the model, lossless on disk. That's a sound design, and it deserves stating as loudly as the warning does.

Verdict: should you install it?

The answer splits, so here's both halves.

The skill: skip it. Type be concise. Two words, three tokens, no install, and an independent benchmark found it matches. The caveman voice buys you roughly 14 extra points over that, for 1,158 tokens of overhead and about ten answers before break-even.

The proxy: genuinely good — conditionally. If your agent spends its day reading CSVs, exports and record dumps, 96% is real and you will feel it. If it reads source code, build logs and nested API responses, you've installed a proxy for almost nothing.

Not hype, but badly labelled. The engineering is better than the meme suggests — a verifiable signed supply chain, and an engine that refuses to write its recovery store into a loosely-permissioned directory. But the caveman is the marketing; the Go code is the product, and the part being shared the most is the part worth the least.

The broader lesson costs nothing: before you install something to save tokens, try asking for less. My entire control test was two words long.

Methodology: n=3 per variant on a single task with one model, so read these as "on this task", not "in general". Output-token measurements here are not comparable to the project's 33.2% input-token figure — different claims. Tested with caveman 4.0.1 on .NET 10, tokens counted with o200k_base.

This is **Naze Lab* — we break things to find out why.*

Sources: JuliusBrussee/caveman · caveman docs · Max Taylor's "Be brief" benchmark

I tried REA, the #1 trending repo on GitHub — can AI really reverse-engineer a .NET app?

Naze Code — Thu, 15 Oct 2026 08:00:33 +0000

A repo called REA — "Reverse Engineer Anything" picked up about 183,000 stars in a single week and went to #1 on GitHub's weekly trending page. The pitch: plug it into your AI coding agent and it takes apart apps it has never seen the source for — even turning raw machine code back into readable code.

That's a big claim, especially for us .NET developers who like to think an obfuscator or Native AOT keeps our code (and our secrets) safe. So I tested it properly: one small, realistic C# app, compiled three different ways, with REA pointed at each build. And then the question the hype skips — can a plain AI agent already do this without REA at all?

What REA actually is

First, a correction the README buries: REA doesn't decompile anything by itself. It's a coordinator. Your agent asks a question; REA runs real analysis tools on the program and hands back findings with evidence.

For .NET, it has its own reader for the assembly metadata and CIL (bytecode) — static, no need to run the target.
For native machine code, it drives a classic decompiler: Ghidra (the free one from the NSA), Hopper, or IDA.

And here's the part the hype glosses over: a decompiler turns machine code into C-like pseudocode full of names like FUN_140001f00 and param_1. It's the AI that reads that soup, guesses what each piece does, and rewrites it as clean code. So REA is real — but it's "a decompiler plus a smart guess," not an undo button for the compiler.

The test app: Naze Pixel

Not a toy. Naze Pixel is ~105 lines of C# that converts a 24-bit BMP into dithered ASCII art: load the bitmap, grayscale it, shrink it, apply Floyd–Steinberg dithering, map pixels to characters. Like a lot of real apps, it also ships with an upload key baked in.

var image = Bmp.Load(path);
var gray  = Pixels.Grayscale(image);
var small = Pixels.Resize(gray, image.Width, image.Height, width);
var dots  = Pixels.Dither(small);
var art   = Pixels.ToAscii(dots);

Console.WriteLine(art);
if (args.Contains("--share")) Uploader.Share(art);

The secret (the key below is fake, created only for this test):

const string ApiKey   = "nzp_live_7c41e9a0d3b8f2a6";          // FAKE upload key
const string Endpoint = "https://api.nazepixel.example/v1/art";

A real run, at width 72, on a high-contrast "C#" test image:

                        ##########        ####  ###
                      ##############      ###   ###
                     ######     ###    #############
                     #####               ###   ###
                     #####               ###  ###
                     #####      #####  #############
                      ##############    ###  ####
                        ##########      ###  ###

     ################## ## ## # # # # # # #  #
     ########## ## # # ## ## ## ## # # # # #  # # # # #  #
     ####### ########### ## # ## # # # #   # #   #          #

Would POST 1480 chars to https://api.nazepixel.example/v1/art with key ...f2a6

I compiled it three ways and, to keep the binaries from leaking my machine, built with <DebugType>none</DebugType> and <Deterministic>true</Deterministic> (otherwise the PDB path with your Windows username ends up inside the binary).

Test 1 — the normal .NET build

REA's .NET reader on NazePixel.dll returns 114 KB of JSON in about a second and a half: every method, its signature, a bytecode summary, and every string literal — including our usage text, the endpoint, and the key.

I handed that JSON, and only that JSON, to a fresh AI with no source code. 85 seconds later it had rebuilt the app: the grayscale weights to four decimal places, the 7/3/5/1 dithering pattern, the lot.

To prove the rebuild was faithful, I recompiled the AI's version, ran it on the same image, and fingerprinted both outputs with SHA-256:

ours    317eb0c60108775b9e6a88a7f371e21eb34fc11cc607fc3a66f6938ba6d92261
ai      317eb0c60108775b9e6a88a7f371e21eb34fc11cc607fc3a66f6938ba6d92261

Same hash means byte-for-byte identical output. (A SHA-256 is a file's fingerprint: change one character and the hash is completely different.)

Control, no REA: given the bare .dll and told "use any tools you like," the same agent found ILSpy (a free .NET decompiler, already installed) and had real C# back in 41 seconds.

Test 2 — the obfuscated build

Next I ran the build through Obfuscar, a free open-source obfuscator. Every class and method was renamed to invisible Unicode space characters, and every string was encrypted. REA's string list came back empty.

So, can the AI still make sense of it? Given REA's output only, after about three minutes it had:

Rebuilt the whole algorithm from the bytecode.
Cracked the encryption on paper: every byte XOR'd with its position and a fixed value — b ^ i ^ 0xAA. I verified that myself, and it's right.
Not actually read the strings — it could only guess them by length (it guessed the share flag was --debug; it's really --share).

But it made one prediction: the key is a constant, and constants live in the metadata, so it's probably still plain text. So I looked:

> search the obfuscated .dll for a UTF-16 "nzp_live_..." string
nzp_live_7c41e9a0d3b8f2a6

There it is — the full key, in plain text, inside the "obfuscated" file. The obfuscator renamed everything to invisible characters; the one thing I actually wanted hidden, it never touched.

Control, no REA: 56 seconds to decompile it, find the encryption, and decrypt every string (key included) with a couple of lines of Python.

Test 3 — Native AOT (machine code)

This is the case the hype is really about. dotnet publish -p:PublishAot=true produces a 1.1 MB .exe of pure x64 machine code — no CIL bytecode at all. Here's what our Dither function looks like now:

140001f00  48 89 5c 24 08 57 48 83 ec 20 8b f2 48 8b d9 ...

REA loads the exe into Ghidra, which finds 3,627 functions — almost all of them the .NET runtime. Our code is a few needles in that haystack. Given REA (and only REA), the AI searched for our strings, followed the code that used them, and decompiled our functions one at a time. About 18 minutes later: the whole app, same weights, same dithering, same key — and it even labeled each function with its address in the exe.

I compiled that machine-code rebuild too, and its output has the same hash as the original:

ours     317eb0c6...6d92261
rebuild  317eb0c6...6d92261

Byte-for-byte, reconstructed from machine code. That part of the hype holds.

Control, no Ghidra: under 4 minutes. The agent wrote its own disassembler scripts in Python and recovered the same constants, the same key, and even the real class names (.NET leaves those in the exe for stack traces). One catch worth flagging: it also ran the unknown exe to see what it did — fine for my own app, not something you want an agent doing to a stranger's binary.

So, real or hype?

Build	With REA	Without REA (plain AI)
Normal .NET	85 s, byte-identical rebuild	41 s (ILSpy)
Obfuscated	~3 min, key recovered	56 s, key recovered
Native AOT	~18 min, byte-identical rebuild	~4 min, key + class names

REA is real. It's careful, it's static for .NET, and on pure machine code it genuinely helped the AI rebuild my app exactly. But in every single test, the same AI without it got there too — and faster. For apps this size, the AI was doing the reverse engineering; REA or no REA.

Where REA earns its stars is the case I didn't test: big native applications where you want a real decompiler plus evidence you can check, instead of an agent improvising with Python. For a 105-line C# app, it's overkill. The capability is real; the "you need this tool" framing is the hype — only half true.

The actual lesson for .NET developers

This was never really about one trending repo. It's the same lesson three ways:

Obfuscation slows people down.
Native AOT slows them down more.
Neither keeps a secret.

Anything you ship to a user's machine can be read — strings, keys, endpoints, all of it. A secret baked into your app is just a password with a delivery address. Keep it on a server behind an API you control.

This is **Naze Lab* — we break things to find out why.*

Sources: morluto/rea · REA docs · Ghidra 12.1.4 · Obfuscar · ILSpy · .NET 10 Native AOT.

How big is Hello World in C#? From 76 MB down to 0.73 MB

Naze Code — Sun, 11 Oct 2026 13:26:03 +0000

How big is the smallest C# program? It depends almost entirely on how you publish it. Same one line of code, five different dotnet publish commands, and the result ranges from a 76 MB folder of 191 files to a single 0.73 MB executable.

Machine: .NET SDK 10.0.302, Windows 11 x64. Sizes exclude .pdb files. Start time is the median of 21 runs of "start the process, print, exit", after a warm-up run.

The program under test:

Console.WriteLine("Hello, World!");

The five ways it was published:

("1 default (needs .NET)",  ""),
("2 self-contained",        "--self-contained -r win-x64"),
("3 trimmed single file",   "--self-contained -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true"),
("4 Native AOT",            "-r win-x64 -p:PublishAot=true"),
("5 Native AOT, tiny",      "-r win-x64 -p:PublishAot=true -p:OptimizationPreference=Size " +
                            "-p:InvariantGlobalization=true -p:UseSystemResourceKeys=true -p:StackTraceSupport=false"),

(Each line is appended to dotnet publish Hello.csproj -c Release.) The results:

1 default (needs .NET)
  size:       0.16 MB, 4 files
  start+exit: 39 ms
2 self-contained
  size:       76.63 MB, 191 files
  start+exit: 40 ms
3 trimmed single file
  size:       12.30 MB, 1 files
  start+exit: 132 ms
4 Native AOT
  size:       1.06 MB, 1 files
  start+exit: 7 ms
5 Native AOT, tiny
  size:       0.73 MB, 1 files
  start+exit: 7 ms

Sizes were identical on every run. Start times varied by a few milliseconds (for example 39–41 ms for the default, 132–141 ms for the trimmed single file), so treat them as "on my machine".

1. Default: 0.16 MB, but it isn't the whole story

The default publish is tiny because it contains only your code: Hello.dll, a small Hello.exe launcher and two config files. Everything else, the runtime and the base libraries, has to already be installed on the machine. That's a framework-dependent app. Great when you control the servers; a problem when you hand an .exe to someone without .NET.

2. Self-contained: 76.63 MB, 191 files

--self-contained ships the runtime with the app, so it runs on a machine with no .NET installed. The price: the whole runtime and base class library come along, 191 files for one line of code. Start time is about the same as the default, since it's the same runtime doing the same work.

3. Trimmed single file: 12.30 MB, one file

PublishTrimmed removes the parts of the libraries your code never uses, and PublishSingleFile bundles everything into one .exe. Down to 12 MB and one file.

Two catches:

Trimming can break code that uses reflection. The trimmer can't always see what will be loaded by name at runtime, so it may remove it. It warns you at publish time; take those warnings seriously.
In this test, this build started the slowest: about 130–140 ms, more than three times the default. I didn't dig into why, so I'll just report it: measure before choosing it for something that starts often, like a CLI tool.

4. Native AOT: 1.06 MB, 7 ms

PublishAot compiles everything ahead of time into native machine code. No separate runtime to load and no JIT compiling methods at startup. The result is a single 1 MB executable that started in 7 ms, about five times faster than the default.

The trade-off is that the program can't generate new code at runtime. Anything that relies on that (some reflection-heavy libraries, dynamic proxies, runtime code generation) needs to be AOT-compatible. On Windows, it also needs the Visual Studio C++ build tools installed to link.

5. Native AOT tuned for size: 0.73 MB

Four more switches, each giving up something a Hello World doesn't need:

OptimizationPreference=Size: tell the compiler to prefer smaller code over faster code.
InvariantGlobalization=true: drop culture-specific data (number and date formats per country). Fine here; not fine for an app that formats dates for users in many countries.
UseSystemResourceKeys=true: exception messages become resource keys instead of full text.
StackTraceSupport=false: less information in stack traces.

Result: 0.73 MB, about a hundred times smaller than the self-contained build, and still starting in 7 ms.

Which one should you use?

Web apps and services on servers you control: the default. Small deploys, and the runtime gets patched separately.
A tool you hand to people who may not have .NET: self-contained, or Native AOT if your dependencies support it.
CLI tools, serverless functions, containers where startup time matters: Native AOT is worth trying first.
The size-tuned switches: only when size really matters and you can live without what they remove.

Try the commands above on your machine and post your numbers in the comments. I'm curious how much start times vary.

I make short, tested videos about C# and what happens when you measure it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, .NET application publishing overview, Trim self-contained deployments, Native AOT deployment, Optimize AOT deployments. Tested on .NET SDK 10.0.302 (runtime 10.0.10), Windows 11 x64.

Why LINQ is lazy: IEnumerable and yield in C#, explained by running it

Naze Code — Sun, 11 Oct 2026 13:25:17 +0000

LINQ is lazy: Where and Select don't do anything until you loop over the result. Most people learn that as a rule. But it isn't LINQ magic. It comes straight from yield return, and once you see how yield works, LINQ's behavior stops being surprising.

Four small experiments, run for real on .NET 10 (Release build).

1. Nothing runs until someone asks

static IEnumerable<int> Numbers()
{
    for (var i = 1; i <= 3; i++)
    {
        Console.WriteLine($"  producing {i}");
        yield return i;
    }
}

var numbers = Numbers();
Console.WriteLine("Numbers() called");

foreach (var n in numbers)
    Console.WriteLine($"got {n}");

Numbers() called
  producing 1
got 1
  producing 2
got 2
  producing 3
got 3

Two things to notice:

Calling Numbers() ran none of its body. "Numbers() called" printed first.
After that, producing and consuming take turns. The loop asks for one item, the method runs until the next yield return, hands it over, and pauses there until the loop asks again.

That's exactly why a LINQ query runs when it's read, not when it's written: Where, Select and friends are built the same way.

2. What the compiler turns `yield` into

A method can't really "pause" halfway. So the compiler rewrites an iterator method into a hidden class that remembers where it was. Reflection can find it:

var machine = typeof(Demo).GetNestedTypes(BindingFlags.NonPublic)
    .Single(t => t.Name.Contains("Numbers"));

Console.WriteLine(machine.Name);
foreach (var i in machine.GetInterfaces())
    Console.WriteLine($"  implements {i.Name}");
foreach (var f in machine.GetFields(BindingFlags.Instance | BindingFlags.NonPublic))
    Console.WriteLine($"  {f.FieldType.Name,-8} {f.Name}");

<Numbers>d__0
  implements IEnumerable`1
  implements IEnumerable
  implements IEnumerator`1
  implements IDisposable
  implements IEnumerator
  Int32    <>1__state
  Int32    <>2__current
  Int32    <>l__initialThreadId
  Int32    <i>5__2

<>1__state is where it paused: which yield return to continue after.
<>2__current is the value just yielded (what Current returns).
<i>5__2 is your loop variable i, moved into a field so it survives between calls.
<>l__initialThreadId is a small optimization: the first foreach on the thread that created the sequence can reuse this same object as its enumerator instead of allocating a new one.

The class is both the sequence (IEnumerable) and the cursor (IEnumerator). Each MoveNext() call runs your code up to the next yield return. It also implements IDisposable, which matters in the next part.

3. Infinite sequences and early stops

static IEnumerable<int> Naturals()
{
    try
    {
        for (var n = 1; ; n++) { produced++; yield return n; }   // no exit
    }
    finally { Console.WriteLine("  cleanup ran"); }
}

var firstEvens = Naturals().Where(n => n % 2 == 0).Take(3);

Console.WriteLine(string.Join(", ", firstEvens));
Console.WriteLine($"produced: {produced}");

  cleanup ran
2, 4, 6
produced: 6

The loop has no exit, and it still finished, after producing exactly 6 numbers. Each item is pulled through the chain one at a time, and once Take(3) has three, it stops asking.

And the finally still ran: when the consumer stops early, it disposes the enumerator, and disposing a paused iterator runs its pending finally blocks. ("cleanup ran" prints first because string.Join reads the whole sequence, which disposes it, before the result is printed.) That's what makes it safe to yield from inside a using block that holds a file or a connection.

4. The argument check that runs too late

static IEnumerable<string> ReadLines(string path)
{
    if (path is null) throw new ArgumentNullException(nameof(path));
    foreach (var line in File.ReadLines(path))
        yield return line;
}

IEnumerable<string> lines;
try { lines = ReadLines(null!); }
catch (ArgumentNullException) { Console.WriteLine("caught at the call"); return; }

Console.WriteLine("no exception yet...");
Console.WriteLine(lines.Count());

no exception yet...
Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'path')
   at P4.Bad.ReadLines(String path)+MoveNext() in ...\Parts.cs:line 92
   at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)

(Path shortened.) The null check is part of the iterator body, so like everything else in it, it doesn't run until the first MoveNext(). The try around the call caught nothing. The exception came out of Count(), which could be in a completely different part of the program, long after the bad call.

Fix: split the method. Validate in a normal method, then return a local iterator function.

static IEnumerable<string> ReadLines(string path)
{
    ArgumentNullException.ThrowIfNull(path);   // runs now
    return Iterate(path);

    static IEnumerable<string> Iterate(string path)
    {
        foreach (var line in File.ReadLines(path))
            yield return line;
    }
}

Same calling code:

caught at the call

Recap

Calling an iterator runs nothing. Each MoveNext() runs to the next yield return.
The compiler turns it into a class with a state field, the current value and your locals.
Consumers that stop early dispose the iterator, so finally and using still run.
Validate arguments in a wrapper method, not inside the iterator.

Did part 4 ever bite you? Tell me in the comments.

I make short, tested videos about C# and what's really going on under the hood. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, yield statement, Iterators, Deferred execution and lazy evaluation. Tested on .NET SDK 10.0.302, Release build.

5 ways null gets past C# nullable reference types

Naze Code — Sun, 11 Oct 2026 13:25:11 +0000

Nullable reference types are one of the best things to happen to C#. Turn them on, fix the warnings, and most null bugs show up while you type.

Most, not all. Nullable analysis is a compile-time check of your code. It doesn't change what happens at runtime, and it can't see data that comes from outside. Here are five ways null still gets through. In this project, with <Nullable>enable</Nullable>, four of them build with zero warnings. Every output is copied from actually running them on .NET 10.

1. The `!` that only silences the compiler

string nickname = null!;          // "trust me, it's not null"

Console.WriteLine($"Hi, {nickname.ToUpper()}!");

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

The null-forgiving operator ! tells the compiler to stop warning. That's all it does: no check, no exception at the assignment, nothing at runtime. Every ! is a promise the compiler can't verify.

Fix: if it can be null, say so, and handle it.

string? nickname = null;          // honest: it might be null

Console.WriteLine($"Hi, {nickname?.ToUpper() ?? "friend"}!");

Hi, friend!

2. JSON that doesn't read your annotations

public class User
{
    public string Email { get; set; } = "";
    public string Name { get; set; } = "";
}

var json = """{ "email": "ada@x.dev", "name": null }""";

var user = JsonSerializer.Deserialize<User>(json, JsonSerializerOptions.Web)!;
Console.WriteLine(user.Name.Length);

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

Name is a non-nullable string with a default of "". But the JSON explicitly says null, and by default System.Text.Json sets it, regardless of your annotations. The compiler checked your code; nobody checked the data.

Fix: since .NET 9, you can tell the serializer to enforce the annotations. required also rejects a property that's missing entirely.

public class User
{
    public required string Email { get; set; }
    public required string Name { get; set; }
}

var options = new JsonSerializerOptions(JsonSerializerOptions.Web)
{
    RespectNullableAnnotations = true,
};
var user = JsonSerializer.Deserialize<User>(json, options)!;

Unhandled exception. System.Text.Json.JsonException: The property or field 'name' on type 'T2.Good.User' doesn't allow setting null values. Consider updating its nullability annotation. Path: $.name | LineNumber: 0 | BytePositionInLine: 36.

It still fails, but now it fails at the boundary, with a message that says exactly which field was null, instead of somewhere deep in your code later.

3. Arrays start full of nulls

var names = new string[3];        // string, not string?
names[0] = "Ada";

foreach (var name in names)
    Console.WriteLine(name.Length);

3
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

new string[3] creates three slots, and every slot starts as null. The type says string, not string?, and the compiler doesn't track individual array elements, so no warning.

Fix: use a collection that only contains what you actually put in it.

var names = new List<string>();   // only holds what you add
names.Add("Ada");

foreach (var name in names)
    Console.WriteLine(name.Length);

4. Generic `T?` that isn't nullable

static T? FindFirst<T>(List<T> items, Func<T, bool> match)
{
    foreach (var item in items)
        if (match(item)) return item;
    return default;
}

var ids = new List<int> { 3, 7, 0 };
Console.WriteLine($"first id == 0:  {FindFirst(ids, id => id == 0)}");
Console.WriteLine($"first id > 100: {FindFirst(ids, id => id > 100)}");

first id == 0:  0
first id > 100: 0

"Found 0" and "found nothing" print the same thing. When T is unconstrained and you call it with a value type like int, T? is just int, not int?. default is 0. (You can't even check is null on it; that doesn't compile.)

Fix: return whether you found something separately, with the Try pattern.

static bool TryFindFirst<T>(List<T> items, Func<T, bool> match, out T found)
{
    foreach (var item in items)
        if (match(item)) { found = item; return true; }
    found = default!;
    return false;
}

var hasZero = TryFindFirst(ids, id => id == 0, out var zero);
var hasBig  = TryFindFirst(ids, id => id > 100, out var big);
Console.WriteLine(hasZero ? $"found {zero}" : "not found");
Console.WriteLine(hasBig  ? $"found {big}"  : "not found");

found 0
not found

5. The warning everyone scrolls past

This one the compiler does catch:

string? coupon = FindCoupon("WELCOME");

Console.WriteLine(coupon.Length);  // the compiler warns here...

warning CS8602: Dereference of a possibly null reference.

But it's a warning. The build succeeds, and at runtime:

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.

Fix: make nullable warnings errors, so this can't be merged.

<WarningsAsErrors>nullable</WarningsAsErrors>

error CS8602: Dereference of a possibly null reference.

The build fails.

Recap

! silences the compiler; it doesn't prevent null. Treat each one as a code-review question.
Deserializers ignore annotations by default. Use RespectNullableAnnotations and required.
Arrays of reference types start as nulls. Prefer lists, or fill every slot.
Unconstrained T? with a value type is just T. Use the Try pattern.
Make nullable warnings errors.

Which of these have you hit? I'd guess number 2 is the most common in real APIs. Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Nullable reference types, Respect nullable annotations in System.Text.Json, Required properties, Unconstrained type parameters. Tested on .NET SDK 10.0.302.

What if the garbage collector never runs? 5 C# GC experiments

Naze Code — Sun, 11 Oct 2026 13:25:06 +0000

Most C# developers never think about the garbage collector, until a service's memory climbs all day, or someone adds GC.Collect() "to be safe". So I ran five experiments to see what it actually does.

Machine: .NET 10.0.10, Windows 11, Release build, workstation GC. Each test ran in its own fresh process, three times; ranges are from those three runs.

1. A hundred million objects of garbage

int gen0 = GC.CollectionCount(0);
int gen1 = GC.CollectionCount(1);
int gen2 = GC.CollectionCount(2);
var timer = Stopwatch.StartNew();

for (var i = 0; i < 100_000_000; i++)
{
    var box = new Box(i);          // garbage immediately
}

Console.WriteLine($"100,000,000 objects in {timer.ElapsedMilliseconds} ms");
Console.WriteLine($"gen0 collections: {GC.CollectionCount(0) - gen0}");
Console.WriteLine($"gen1 collections: {GC.CollectionCount(1) - gen1}");
Console.WriteLine($"gen2 collections: {GC.CollectionCount(2) - gen2}");

100,000,000 objects in 180 ms
gen0 collections: 183
gen1 collections: 1
gen2 collections: 0

(180–247 ms over three runs.) A hundred million allocations in about a fifth of a second, and the GC ran 183 times without me noticing.

The .NET GC is generational. New objects start in generation 0, and a gen0 collection only has to deal with what's still alive there. Here, almost nothing is still alive, so each collection is tiny. Short-lived garbage is the cheapest kind of memory you can use.

2. Keep everything

Now the opposite: never let anything become garbage. This test runs with the heap capped at 256 MB (DOTNET_GCHeapHardLimit), so it fails quickly instead of eating the machine's RAM.

// launched with DOTNET_GCHeapHardLimit = 256 MB
var keep = new List<Box>();
try
{
    while (true) keep.Add(new Box(keep.Count));
}
catch (OutOfMemoryException)
{
    var count = keep.Count;
    keep = null!;
    Console.WriteLine($"Out of memory after {count:N0} objects");
}

Out of memory after 7,874,433 objects

About 7.9 million small objects fill 256 MB (each one plus its slot in the list is roughly 32 bytes). The GC was running the whole time; it just couldn't free anything, because every object was still reachable from keep.

That's what a "memory leak" is in .NET: not memory the GC forgot, but references you forgot. A static list, a cache with no eviction, an event handler that's never unsubscribed.

3. Turning the GC off

.NET lets you ask for a stretch of code with no collections at all:

GC.TryStartNoGCRegion(200_000_000);          // "don't collect for 200 MB"
var before = GC.CollectionCount(0);

var keep = new Box[1_000_000];
for (var i = 0; i < keep.Length; i++) keep[i] = new Box(i);

Console.WriteLine($"collections inside region: {GC.CollectionCount(0) - before}");
GC.EndNoGCRegion();

collections inside region: 0

It works, as long as you stay inside the budget. (The counter starts after entering the region, because entering it can trigger one collection first.)

Now give it a 10 MB budget and allocate about 32 MB:

GC.TryStartNoGCRegion(10_000_000);           // only 10 MB this time

var keep = new Box[1_000_000];               // ~32 MB of objects
for (var i = 0; i < keep.Length; i++) keep[i] = new Box(i);

GC.EndNoGCRegion();

Unhandled exception. System.InvalidOperationException: NoGCRegion mode must be set.

No warning when the budget ran out. The region quietly ended, the GC collected as usual, and the only sign was the exception at the very end, when there was no region left to end.

4. Small collection vs full collection

With 5 million long-lived objects on the heap:

var timer = Stopwatch.StartNew();
GC.Collect(0);
Console.WriteLine($"gen0 collection: {timer.Elapsed.TotalMilliseconds:0.00} ms");

timer.Restart();
GC.Collect(2);
Console.WriteLine($"full collection: {timer.Elapsed.TotalMilliseconds:0.00} ms");

gen0 collection: 2.30 ms
full collection: 32.60 ms

(2.30–2.68 ms vs 32.60–33.84 ms.) A full collection has to walk every live object, so it took about 14 times longer. The more long-lived data you keep around, the more each full GC costs.

5. Calling `GC.Collect()` "to be safe"

A thousand small work items, with a realistic heap of a million live objects. Once letting the GC decide, once with GC.Collect() after every item:

var timer = Stopwatch.StartNew();
Work(forceGc: false);
Console.WriteLine($"let the GC decide:     {timer.ElapsedMilliseconds} ms");

timer.Restart();
Work(forceGc: true);                          // GC.Collect() after every item
Console.WriteLine($"GC.Collect() each time: {timer.ElapsedMilliseconds} ms");

let the GC decide:     1 ms
GC.Collect() each time: 6839 ms

(6,839–6,921 ms over three runs.) One millisecond versus about seven seconds. GC.Collect() forces a full, blocking collection every time, which is the expensive kind from part 4, a thousand times over.

Recap

Short-lived objects are cheap; generational GC is built for them.
Leaks in .NET are references you kept, not memory the GC missed.
A no-GC region ends silently when you exceed its budget.
Full collections cost more the more long-lived data you hold.
Don't call GC.Collect(). Let the GC decide.

What's the weirdest memory issue you've had to track down in .NET? Tell me in the comments.

I make short, tested videos about C# and what happens when you measure it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Fundamentals of garbage collection, GC.TryStartNoGCRegion, GC.EndNoGCRegion, GC configuration settings. Tested on .NET 10.0.10, Windows 11, Release build, 3 runs each.

C# records, structs and equality: what == really compares

Naze Code — Sun, 11 Oct 2026 13:25:02 +0000

== looks like the simplest operator in C#. But what it compares depends on what you're comparing, and records, which were supposed to make equality "just work", have a couple of edges that bite in real code.

Four small experiments, each run for real on .NET 10 (Release build).

1. Class vs record

public class UserClass(string name, string email)
{
    public string Name { get; } = name;
    public string Email { get; } = email;
}

public record UserRecord(string Name, string Email);

var a = new UserClass("Ada", "ada@x.dev");
var b = new UserClass("Ada", "ada@x.dev");
Console.WriteLine($"class:  {a == b}");

var c = new UserRecord("Ada", "ada@x.dev");
var d = new UserRecord("Ada", "ada@x.dev");
Console.WriteLine($"record: {c == d}");

class:  False
record: True

For a class, == asks "is this the same object?" Two separate objects with identical data are not equal.

For a record, the compiler generates Equals, GetHashCode, == and != for you, and they compare each field. Same data, equal records. That's the main reason to use a record for data like DTOs, messages and value objects.

2. A record holding a list

public record Order(string Customer, List<string> Items);

var first  = new Order("Ada", ["laptop", "mouse"]);
var second = new Order("Ada", ["laptop", "mouse"]);

Console.WriteLine($"Equal? {first == second}");

Equal? False
Items equal? False · same contents? True

Same customer and same items, but not equal. Record equality compares each field with that field type's own equality. string compares by value, but List<string> is a class, so its equality is reference equality. Two different lists with the same contents aren't "equal" to it.

Takeaway: a record is only value-equal "all the way down" if its fields are. For collections, either compare them yourself (SequenceEqual), or override Equals in the record. Don't assume it.

3. `with` makes a shallow copy

var original = new Order("Ada", ["laptop"]);
var copy = original with { Customer = "Bob" };

copy.Items.Add("headphones");

Console.WriteLine($"Bob's items: {string.Join(", ", copy.Items)}");
Console.WriteLine($"Ada's items: {string.Join(", ", original.Items)}");

Bob's items: laptop, headphones
Ada's items: laptop, headphones

with copies each field's value. For a list, the value is a reference, so Bob's order and Ada's order now share the same list. Adding to one adds to both.

Takeaway: if a record holds something mutable, with doesn't protect you. Give the copy its own new list when you use with, or use immutable collections in records.

4. The struct whose `Equals` allocates

Two structs with the same fields, one a plain struct, one a record struct:

public struct Point
{
    public string Label;
    public int X, Y;
}

public record struct PointRecord(string Label, int X, int Y);

Search a list of 2,000 of each, 1,000 times, for an item that isn't there:

var timer = Stopwatch.StartNew();
for (var i = 0; i < 1_000; i++)
    points.Contains(new Point { Label = "p", X = -1, Y = -1 });
Console.WriteLine($"struct:        {timer.ElapsedMilliseconds} ms");

timer.Restart();
for (var i = 0; i < 1_000; i++)
    records.Contains(new PointRecord("p", -1, -1));
Console.WriteLine($"record struct: {timer.ElapsedMilliseconds} ms");

struct:        244 ms
record struct: 16 ms
allocated per Contains over 2,000 items: struct 320,000 B · record struct 0 B

About 15 times slower, and 320 KB of garbage for a single Contains call (160 bytes per comparison).

A plain struct that doesn't override Equals gets ValueType.Equals. When the struct contains a reference-type field (the string here), that default implementation falls back to reflection to compare the fields, boxing as it goes. A record struct gets a generated, field-by-field Equals instead, with no reflection and no allocations.

Takeaway: if you put structs in lists, dictionaries or hash sets, make them record structs, or implement IEquatable<T> yourself.

Recap

Class == compares references. Record == compares fields.
Record equality is only as deep as its fields' equality; lists compare by reference.
with copies references, so mutable fields end up shared.
A plain struct's default Equals can use reflection and allocate. Use record struct or IEquatable<T>.

Have you been bitten by record equality on a collection? Tell me in the comments.

I make short, tested videos about C# and what's really going on under the hood. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Records, ValueType.Equals (remarks on reflection), with expression. Tested on .NET SDK 10.0.302, Release build. Timings are from one run; the research runs ranged 229–258 ms vs 16–17 ms.

5 C# DateTime bugs that pass every test

Naze Code — Sun, 11 Oct 2026 07:28:17 +0000

Date and time bugs are the worst kind: the code is correct on the day you test it, in the time zone you test it in. Then the clocks change, or a user in another country logs in, or the CI server runs on a Sunday.

Here are five, each replayed for real on .NET 10. The machine running them is set to UTC+8 (no daylight saving). That detail matters for two of them, which is exactly the point.

1. Subtracting local times across a clock change

// Night shift in New York, the night the clocks jump forward
var start = new DateTime(2026, 3, 8, 1, 0, 0);
var end   = new DateTime(2026, 3, 8, 4, 0, 0);

var hours = (end - start).TotalHours;
Console.WriteLine($"Hours paid: {hours}");

Hours paid: 3

On that night in New York, the clock goes from 1:59 straight to 3:00. 2 AM never happens. The shift lasted two real hours, but subtracting wall-clock times knows nothing about that, so it pays three.

Fix: convert both ends to UTC in the right time zone, then subtract.

var ny = TimeZoneInfo.FindSystemTimeZoneById("America/New_York");

var hours = (TimeZoneInfo.ConvertTimeToUtc(end, ny)
           - TimeZoneInfo.ConvertTimeToUtc(start, ny)).TotalHours;

Hours paid: 2

The opposite night in November is harder: 1 AM happens twice, and a plain DateTime can't say which one it means. ConvertTimeToUtc treats an ambiguous time as standard time, so for those shifts you need to record the offset when the time is captured, not reconstruct it later.

2. `DateTime.Parse` and the vanishing `Z`

var json = "2026-10-12T09:00:00Z";      // 9 AM UTC, from the API

var meeting = DateTime.Parse(json);
Console.WriteLine($"Meeting: {meeting:HH:mm} ({meeting.Kind})");

Meeting: 17:00 (Local)

The Z means UTC. DateTime.Parse honors it by converting to the machine's local time zone and marking the result Local. On a UTC+8 machine, 9 AM becomes 5 PM. On a machine set to UTC, local time is UTC, so the bug is invisible there.

Fix: parse into DateTimeOffset, which keeps the offset that was in the string.

var meeting = DateTimeOffset.Parse(json, CultureInfo.InvariantCulture);
Console.WriteLine($"Meeting: {meeting:HH:mm} (offset {meeting.Offset})");

Meeting: 09:00 (offset 00:00:00)

3. `==` that ignores time zones

var deadlineUtc = new DateTime(2026, 10, 12, 9, 0, 0, DateTimeKind.Utc);
var nowLocal    = new DateTime(2026, 10, 12, 9, 0, 0, DateTimeKind.Local);

Console.WriteLine($"Same moment? {deadlineUtc == nowLocal}");

Same moment? True

On this machine, those two are 8 hours apart. DateTime equality compares the clock reading and ignores Kind completely.

Fix: DateTimeOffset compares actual moments in time.

var deadline = new DateTimeOffset(2026, 10, 12, 9, 0, 0, TimeSpan.Zero);
var now      = new DateTimeOffset(2026, 10, 12, 9, 0, 0, TimeSpan.FromHours(8));

Console.WriteLine($"Same moment? {deadline == now}");

Same moment? False

4. `AddDays` across a clock change

DateTimeOffset fixed traps 2 and 3. But it has its own blind spot (Ny is TimeZoneInfo.FindSystemTimeZoneById("America/New_York")):

// Daily standup, 9 AM New York. Saturday's meeting:
var saturday = new DateTimeOffset(2026, 3, 7, 9, 0, 0, TimeSpan.FromHours(-5));

var sunday = saturday.AddDays(1);
Console.WriteLine($"Sunday: {TimeZoneInfo.ConvertTime(sunday, Ny):HH:mm} New York time");

Sunday: 10:00 New York time

A DateTimeOffset has a fixed offset, not a time zone. AddDays(1) adds exactly 24 hours and keeps -05:00, but by Sunday morning New York has moved to -04:00. So the "9 AM" standup lands at 10.

Fix: do calendar math in wall-clock time, then ask the time zone for that day's offset.

var saturday = new DateTime(2026, 3, 7, 9, 0, 0);

var sundayLocal = saturday.AddDays(1);                  // wall clock: 9 AM
var sunday = new DateTimeOffset(sundayLocal, Ny.GetUtcOffset(sundayLocal));
Console.WriteLine($"Sunday: {sunday:HH:mm} New York time (offset {sunday.Offset})");

Sunday: 09:00 New York time (offset -04:00:00)

5. A test that depends on what day it is

public class Promo
{
    public bool IsWeekendSale() =>
        DateTime.Now.DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

// Test: "no sale on a weekday"
var promo = new Promo();
Console.WriteLine(promo.IsWeekendSale() ? "FAIL: sale is on" : "PASS");

FAIL: sale is on

I ran it on a Sunday. From Monday to Friday this test passes, so it'll fail for whoever happens to work on a weekend, and nobody will be able to reproduce it on Monday.

Fix: don't read the clock directly; take a TimeProvider (built into .NET 8 and later).

public class PromoWithClock(TimeProvider clock)
{
    public bool IsWeekendSale() =>
        clock.GetLocalNow().DayOfWeek is DayOfWeek.Saturday or DayOfWeek.Sunday;
}

Production passes TimeProvider.System. Tests pass a FakeTimeProvider (from the Microsoft.Extensions.TimeProvider.Testing package) set to whatever moment they need:

var clock = new FakeTimeProvider(
    new DateTimeOffset(2026, 10, 14, 12, 0, 0, TimeSpan.Zero));   // a Wednesday
var promo = new PromoWithClock(clock);
Console.WriteLine(promo.IsWeekendSale() ? "FAIL: sale is on" : "PASS");

PASS

Recap

Durations: convert to UTC in the right time zone before subtracting.
Parse timestamps with an offset into DateTimeOffset, not DateTime.
Compare moments with DateTimeOffset; DateTime == ignores Kind.
Calendar math ("same time tomorrow") in wall-clock time, then get the offset from the time zone.
Inject TimeProvider; never read DateTime.Now inside logic you want to test.

What's the worst date bug you've shipped? Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Choosing between DateTime, DateTimeOffset and TimeZoneInfo, TimeZoneInfo.ConvertTimeToUtc, TimeProvider, FakeTimeProvider. Tested on .NET SDK 10.0.302, machine set to UTC+8.

Are exceptions really slow in C#? I threw a million to find out

Naze Code — Sun, 11 Oct 2026 07:28:14 +0000

"Exceptions are slow" gets repeated in every C# code review, usually without a number attached. So I measured it. Five experiments, each run three times on an idle machine: .NET 10.0.10, Windows 11, Release build, after a warm-up. The ranges below are from those three runs.

Absolute timings depend a lot on the machine and what else it's doing (the runs in the video below were about twice as slow as these), so focus on the ratios.

1. What does one throw cost?

const int count = 1_000_000;
var timer = Stopwatch.StartNew();

for (var i = 0; i < count; i++)
{
    try { throw new InvalidOperationException("nope"); }
    catch (InvalidOperationException) { }
}

Console.WriteLine($"{count:N0} throws: {timer.ElapsedMilliseconds} ms");
Console.WriteLine($"one throw: {timer.Elapsed.TotalNanoseconds / count:N0} ns");

1,000,000 throws: 959 ms
one throw: 959 ns

About 1 microsecond per throw and catch (950–963 ns over three runs). For a real error that happens once in a while, that's nothing. For something that happens on every request, it adds up fast.

2. Does a `try` block cost anything if nothing throws?

var timer = Stopwatch.StartNew();
for (var i = 0; i < count; i++) sink += Work(i);
Console.WriteLine($"no try:   {timer.ElapsedMilliseconds} ms");

timer.Restart();
for (var i = 0; i < count; i++)
{
    try { sink += Work(i); }
    catch (Exception) { sink--; }
}
Console.WriteLine($"with try: {timer.ElapsedMilliseconds} ms");

100 million calls each:

no try:   82 ms
with try: 102 ms

Three runs: 81–82 ms vs 102–103 ms. So in this tight loop the try version was consistently about 20 ms slower over 100 million calls, which is about 0.2 nanoseconds per call.

That's not zero, and the video called it free, which these runs don't support. But compare it with part 1: one throw costs about 5,000 times more than entering a try. .NET doesn't run any setup code for a try block; the runtime keeps a table of protected regions and only looks at it when something is thrown. Wrapping code in try is not where your time goes.

3. Does it matter how deep the throw is?

static void Dive(int depth)
{
    if (depth == 0) throw new InvalidOperationException("bottom");
    Dive(depth - 1);
}

Throwing from 1, 10 and 50 calls deep, 100,000 times each:

depth  1: 1,176 ns per throw
depth 10: 1,163 ns per throw
depth 50: 1,181 ns per throw

Across three runs, all depths stayed between 1,163 and 1,215 ns, with no trend. At these depths, the number of throws matters, not how far they travel.

4. `int.Parse` + catch vs `int.TryParse`

A million strings that aren't numbers:

var timer = Stopwatch.StartNew();
var bad = 0;
foreach (var text in Inputs)
{
    try { int.Parse(text); }
    catch (FormatException) { bad++; }
}
Console.WriteLine($"Parse + catch: {timer.ElapsedMilliseconds} ms ({bad:N0} bad)");

timer.Restart();
bad = 0;
foreach (var text in Inputs)
    if (!int.TryParse(text, out _)) bad++;
Console.WriteLine($"TryParse:      {timer.ElapsedMilliseconds} ms ({bad:N0} bad)");

Parse + catch: 1434 ms (1,000,000 bad)
TryParse:      3 ms (1,000,000 bad)

Same answer, roughly 480 times faster. This is where "exceptions are slow" is true in practice: using them for an outcome you expect. Bad user input, a missing key or a cache miss isn't exceptional. Use the Try pattern for those.

5. `throw ex` vs `throw`

Not a speed issue, but the most common exception mistake I see:

static void WithThrowEx()
{
    try { SaveOrder(); }
    catch (Exception ex) { throw ex; }
}

static void WithThrow()
{
    try { SaveOrder(); }
    catch (Exception) { throw; }
}

The top two frames of each stack trace:

throw ex: X5.WithThrowEx  <-  X5.Run
throw   : X5.SaveOrder  <-  X5.WithThrow

throw ex restarts the stack trace at the catch, so SaveOrder, the method that actually failed, has disappeared. throw; keeps it. A default dotnet build already warns about it:

warning CA2200: Re-throwing caught exception changes stack information

Recap

One throw costs about a microsecond. Fine for real errors, not for normal control flow.
A try block costs almost nothing when nothing throws (about 0.2 ns per call here).
Depth barely mattered. Throw less, not shallower.
Expected failures belong in TryParse / TryGetValue, not in catch.
Rethrow with throw;, never throw ex;.

Run these on your machine and post your numbers in the comments. I'm curious how much they vary.

I make short, tested videos about C# and what happens when you measure it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Best practices for exceptions, Exceptions and performance, CA2200. Tested on .NET 10.0.10, Windows 11, Release build, 3 runs each.

What async/await really compiles to in C# (and when ValueTask is worth it)

Naze Code — Sun, 11 Oct 2026 07:28:11 +0000

Most of us use async/await every day without knowing what it turns into. That's fine, until you need to answer a question like "should this method return ValueTask?" and realize the answer depends on what await actually does.

So let's look. Four small experiments, each run for real on .NET 10 (Release build unless noted), and one practical decision at the end.

1. What runs where, and in what order

Console.WriteLine($"1. caller             thread {Environment.CurrentManagedThreadId}");
var task = LoadAsync();
Console.WriteLine($"3. caller continues   thread {Environment.CurrentManagedThreadId}");
await task;

static async Task LoadAsync()
{
    Console.WriteLine($"2. LoadAsync starts   thread {Environment.CurrentManagedThreadId}");
    await Task.Delay(100);
    Console.WriteLine($"4. after the await    thread {Environment.CurrentManagedThreadId}");
}

1. caller             thread 2
2. LoadAsync starts   thread 2
3. caller continues   thread 2
4. after the await    thread 5

Two things people often get wrong:

Calling an async method doesn't start a new thread. LoadAsync runs synchronously, on the caller's thread, right up to its first await of something that isn't finished yet.
At that await, the method returns to the caller (line 3) with an unfinished Task. When the delay completes, the rest of the method runs. In a console app there's no UI thread to return to, so it ran on a thread pool thread (5 here; it could also happen to be the same one).

2. The class (or struct) the compiler writes for you

Take an ordinary async method:

public static async Task<int> CountOrdersAsync(int id)
{
    var user = await GetUserAsync(id);
    var orders = await GetOrdersAsync(user);
    return orders;
}

The compiler rewrites it into a hidden type. Reflection can find it:

var machine = typeof(Shop).GetNestedTypes(BindingFlags.NonPublic)
    .Single(t => t.Name.Contains("CountOrdersAsync"));

Console.WriteLine($"{machine.Name}   struct: {machine.IsValueType}");
foreach (var i in machine.GetInterfaces())
    Console.WriteLine($"  implements {i.Name}");
foreach (var f in machine.GetFields(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic))
    Console.WriteLine($"  {f.FieldType.Name,-24} {f.Name}");

Release build:

<CountOrdersAsync>d__0   struct: True
  implements IAsyncStateMachine
  Int32                    <>1__state
  AsyncTaskMethodBuilder`1 <>t__builder
  Int32                    id
  TaskAwaiter`1            <>u__1
  TaskAwaiter`1            <>u__2

That's the whole trick:

<>1__state remembers which await you're paused at, so the method can resume in the right place.
<>t__builder creates and completes the Task<int> the caller gets.
id is your parameter, kept so it survives across awaits.
<>u__1 and <>u__2 hold the awaiter for each of the two awaits.

Notice that user and orders aren't fields. In Release, the compiler only keeps locals that are still needed after an await.

Debug build, same code:

<CountOrdersAsync>d__0   struct: False
  implements IAsyncStateMachine
  Int32                    <>1__state
  AsyncTaskMethodBuilder`1 <>t__builder
  Int32                    id
  String                   <user>5__1
  Int32                    <orders>5__2
  String                   <>s__3
  Int32                    <>s__4
  TaskAwaiter`1            <>u__1
  TaskAwaiter`1            <>u__2

In Debug it's a class, and every local (plus a couple of compiler temporaries) becomes a field. In Release it's a struct, and it only moves to the heap if the method actually has to pause.

3. The fast path: awaiting something that's already done

var cached = Task.FromResult(42);

Console.WriteLine($"before   thread {Environment.CurrentManagedThreadId}");
var value = await cached;              // already finished
Console.WriteLine($"after    thread {Environment.CurrentManagedThreadId}");

before   thread 5
after    thread 5

await first asks the task "are you already complete?" If yes, it just takes the result and keeps going, with no pause, no scheduling and no thread hop. This fast path is why the next part matters.

4. What each call costs

A price lookup that's almost always served from a cache, written twice, once with each return type:

static async Task<int> GetPriceAsync(int id)       // usually cached
{
    if (Cache.TryGetValue(id, out var price)) return price;
    await Task.Delay(10);
    return 0;
}

static async ValueTask<int> GetPriceValueAsync(int id)
{
    if (Cache.TryGetValue(id, out var price)) return price;
    await Task.Delay(10);
    return 0;
}

Measured with GC.GetTotalAllocatedBytes over 100,000 calls, after a warm-up:

Task<int>, cached            72 bytes per call
ValueTask<int>, cached        0 bytes per call
really waits                 96 bytes per call

Task<int>, cache hit: 72 bytes. The method never pauses, but it still has to hand back a Task<int> object, and that's an allocation. (The runtime caches a few common results, but not arbitrary values like this one.)
ValueTask<int>, cache hit: 0 bytes. A ValueTask is a struct that can carry the result directly, so nothing goes on the heap.
A method that really waits: 96 bytes. When it pauses, the state machine from part 2 has to move to the heap so it can be resumed later. ValueTask doesn't avoid that.

So when is `ValueTask` worth it?

When a method usually completes synchronously (cache hits, buffered reads, already-validated input) and it's called often enough that the allocations matter. That's the one case where it saves real work.

Otherwise, stay with Task. ValueTask comes with rules: await it once, don't store it to await later, and don't await it from two places at once. A Task has none of those restrictions.

Recap

An async method runs synchronously until its first await of something unfinished.
The compiler turns it into a state machine: a state number, a builder, and only the locals that must survive an await.
Awaiting a completed task takes a fast path: no pause, no thread switch.
Task<T> allocates even when nothing waits. ValueTask<T> doesn't, but only use it for hot paths that usually complete synchronously.

Did any of this surprise you? I'd like to hear which part in the comments.

I make short, tested videos about C# and what's going on under the hood. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Task asynchronous programming model, ValueTask<TResult>; .NET Blog, How async/await really works in C#. Tested on .NET SDK 10.0.302, Release build unless noted.

5 ways Cancel doesn't actually cancel in C#

Naze Code — Sun, 11 Oct 2026 06:28:48 +0000

A user clicks Export, changes their mind, and clicks Cancel. The spinner goes away. On the server, the export keeps running to the end and saves a file nobody wants.

CancellationToken only works if every piece of code along the way cooperates. Here are five ways it quietly doesn't. Each demo logs a timestamp, the "Cancel" click is simulated, and every output is copied from actually running it on .NET 10. (The demo harness prints Cancelled cleanly when the task ends with a cancellation, and (done) when it runs to completion.)

1. Passing the token to `Task.Run` and nowhere else

using var cts = new CancellationTokenSource();
var work = Task.Run(() => BuildReport(), cts.Token);

await Task.Delay(500);
cts.Cancel();                     // user clicks Cancel
Log.Write("Cancel clicked");

await work;

static void BuildReport()
{
    for (var row = 1; row <= Report.Rows; row++)
        Thread.Sleep(300);        // slow work, row by row
    Report.Save(Report.Rows);
}

[0.5s] Cancel clicked
[3.1s] Report saved (10/10 rows)
[3.1s] (done)

Cancelled at half a second, finished anyway at three. The token you give Task.Run is only used to skip the work if it hasn't started yet. Once BuildReport is running, nothing inside it knows about the token.

Fix: pass the token into the work and check it.

var work = Task.Run(() => BuildReport(cts.Token), cts.Token);

static void BuildReport(CancellationToken ct)
{
    for (var row = 1; row <= Report.Rows; row++)
    {
        ct.ThrowIfCancellationRequested();
        Thread.Sleep(300);        // slow work, row by row
    }
    Report.Save(Report.Rows);
}

[0.5s] Cancel clicked
[0.6s] Cancelled cleanly

2. Taking a token and not passing it on

public static async Task<string> LoadPricesAsync(CancellationToken ct)
{
    var prices = await Api.FetchAsync("prices");
    return prices;
}

[0.5s] Cancel clicked
[3.0s] Loaded prices
[3.0s] (done)

The method accepts ct, so it looks cancellable. But FetchAsync, like most .NET APIs, takes the token as an optional parameter, so forgetting it compiles without a word.

Fix: forward it.

var prices = await Api.FetchAsync("prices", ct);

[0.5s] Cancel clicked
[0.5s] Cancelled cleanly

There's an analyzer rule for exactly this, CA2016, but in my test it didn't show up in a normal build until I turned it on in .editorconfig:

dotnet_diagnostic.CA2016.severity = warning

3. Stopping quietly instead of loudly

public static async Task ExportAsync(CancellationToken ct)
{
    var rows = 0;
    while (rows < Report.Rows)
    {
        if (ct.IsCancellationRequested) break;   // stop quietly
        await Task.Delay(300);
        rows++;
    }
    Report.Save(rows);
}

[1.0s] Cancel clicked
[1.2s] Report saved (4/10 rows)
[1.2s] (done)

It did stop, but break drops straight into the code after the loop, which saves a partial report as if it were finished. And the caller sees a normal successful return, so it can't tell the export was cancelled.

Fix: throw, and give the token to the delay too, so a cancel interrupts the wait instead of finishing it.

while (rows < Report.Rows)
{
    ct.ThrowIfCancellationRequested();       // stop loudly
    await Task.Delay(300, ct);
    rows++;
}

[1.0s] Cancel clicked
[1.0s] Cancelled cleanly

4. Catching the wrong exception type

try
{
    await SearchAsync(ct);
}
catch (TaskCanceledException)
{
    Log.Write("Search cancelled");
}

static async Task SearchAsync(CancellationToken ct)
{
    foreach (var page in Enumerable.Range(1, 10))
    {
        ct.ThrowIfCancellationRequested();
        await Pages.LoadAsync(page);
    }
}

[1.0s] Cancel clicked
Unhandled exception. System.OperationCanceledException: The operation was canceled.

Cancellation comes in two exception types. A cancelled Task.Delay (and many async APIs) throws TaskCanceledException. ThrowIfCancellationRequested() throws its base class, OperationCanceledException. Catching the narrower one lets the other crash straight through.

Fix: catch the base class, which covers both.

catch (OperationCanceledException)
{
    Log.Write("Search cancelled");
}

[1.0s] Cancel clicked
[1.2s] Search cancelled
[1.2s] (done)

5. A retry loop that retries cancellation

public static async Task SendWithRetryAsync(CancellationToken ct)
{
    for (var attempt = 1; attempt <= 5; attempt++)
    {
        try
        {
            await Api.SendAsync(ct);
            return;
        }
        catch (Exception e)
        {
            Log.Write($"Attempt {attempt} failed: {e.Message}");
        }
    }
    Log.Write("ALERT: order could not be sent");
}

[0.1s] Attempt 1 failed: A task was canceled.
[0.1s] Cancel clicked
[0.1s] Attempt 2 failed: A task was canceled.
[0.1s] Attempt 3 failed: A task was canceled.
[0.1s] Attempt 4 failed: A task was canceled.
[0.1s] Attempt 5 failed: A task was canceled.
[0.1s] ALERT: order could not be sent
[0.1s] (done)

The user cancelled, and the code treated it as an outage: five instant "failures" and an alert that pages someone. catch (Exception) catches cancellation too.

Fix: an exception filter, so cancellation passes straight through the retry.

catch (Exception e) when (e is not OperationCanceledException)
{
    Log.Write($"Attempt {attempt} failed: {e.Message}");
}

[0.1s] Cancel clicked
[0.1s] Cancelled cleanly

Recap

The token you give Task.Run only prevents the start. Pass it into the work.
Forward the token to every call that accepts one. Turn on CA2016.
ThrowIfCancellationRequested(), not a quiet break.
Catch OperationCanceledException, not TaskCanceledException.
Retry loops must let cancellation through: when (e is not OperationCanceledException).

Which of these is hiding in your codebase right now? Tell me in the comments.

I make short, tested videos about C# bugs that compile fine and still break things. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Cancellation in managed threads, Task.Run, CA2016, TaskCanceledException. Tested on .NET SDK 10.0.302.

I pushed C# until it broke: 5 hard limits, tested

Naze Code — Sun, 11 Oct 2026 01:37:23 +0000

Every language has edges. Most of the time you never touch them, until a counter goes negative in production or a service dies with no exception in the logs.

So I went looking for C#'s edges on purpose. Five questions, each answered by actually running the code. Machine: .NET 10.0.10, Windows 11, 20 cores, Release build unless stated. Your timings will differ, so treat them as "on my machine".

1. How high can an `int` count?

int counter = 0;
var timer = Stopwatch.StartNew();

while (true)
{
    counter++;
    if (counter < 0) break;   // went past int.MaxValue
}

Console.WriteLine($"Wrapped to {counter:N0} after {timer.Elapsed.TotalSeconds:F2} s");

Wrapped to -2,147,483,648 after 0.47 s

Half a second to count through every positive int, and then it quietly wraps to the most negative one. No exception, no warning. (In a Debug build the same loop took about 1.1 s.)

C# arithmetic is unchecked by default. If an overflow would be a bug, say so:

int counter = int.MaxValue;
counter = checked(counter + 1);   // no silent wrap

Unhandled exception. System.OverflowException: Arithmetic operation resulted in an overflow.

Useful at work: wrap counters, IDs and money-adjacent math in checked, or turn on overflow checking for the whole project with <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow>.

2. How big can an array get?

Console.WriteLine($"Array.MaxLength: {Array.MaxLength:N0}");

var big = new byte[Array.MaxLength];
Console.WriteLine($"Allocated {big.Length / 1e9:F2} GB");

var tooBig = new byte[Array.MaxLength + 1];

Array.MaxLength: 2,147,483,591
Allocated 2.15 GB
Out of memory.

The first allocation worked. The second, just one element bigger, crashed the process. If you catch the exception instead, its message tells the real story: Array dimensions exceeded supported range.

The limit is the number of elements, not memory. Array.MaxLength is the same for every element type (bigger element types can run out of memory sooner).

Useful at work: more than about 2 billion items, or more than ~2 GB in one byte[], means chunking, streams or memory-mapped files, not a bigger array.

3. How deep can a method recurse?

static int depth = 0;

static void GoDeeper()
{
    depth++;
    if (depth % 1000 == 0) Console.WriteLine($"depth {depth:N0}");
    GoDeeper();
}

try { GoDeeper(); }
catch (Exception e) { Console.WriteLine($"Caught: {e.Message}"); }

depth 15,000
depth 16,000
Stack overflow.

About sixteen thousand calls deep, for this method's frame size. And notice what's missing: Caught: never printed. A stack overflow can't be caught in .NET. The process is simply terminated.

The depth depends on the stack size, so a thread with a bigger stack goes much further:

var thread = new Thread(GoDeeper, maxStackSize: 256 * 1024 * 1024);
thread.Start();
thread.Join();

depth 2,794,000
depth 2,795,000
Stack overflow.

Useful at work: a bigger stack only moves the cliff. If input depth isn't under your control (deep JSON, user-built trees), use a loop with an explicit Stack<T> instead of recursion.

4. A million tasks vs ten thousand threads

var timer = Stopwatch.StartNew();
var tasks = new List<Task>();

for (int i = 0; i < 1_000_000; i++)
    tasks.Add(Task.Delay(1000));

await Task.WhenAll(tasks);
Console.WriteLine($"1,000,000 one-second waits took {timer.Elapsed.TotalSeconds:F2} s");

1,000,000 one-second waits took 1.43 s
peak working set: 227 MB

One after another, those waits would take a million seconds, about 11.6 days. Run as tasks, they finished in under a second and a half. A waiting task doesn't hold a thread; it's just a small object and a timer.

Now the same idea with real threads, a hundred times fewer of them:

var timer = Stopwatch.StartNew();
var threads = new List<Thread>();

for (int i = 0; i < 10_000; i++)
{
    var t = new Thread(() => Thread.Sleep(1000));
    t.Start();
    threads.Add(t);
}

threads.ForEach(t => t.Join());
Console.WriteLine($"10,000 threads took {timer.Elapsed.TotalSeconds:F2} s");

10,000 threads took 1.50 s
peak working set: 321 MB

Ten thousand threads worked here, but they used more memory than a million tasks.

To be precise about what this shows: waiting is cheap with tasks. It doesn't mean a million pieces of CPU work would finish in 1.4 seconds.

Useful at work: for I/O (HTTP calls, database queries, timers), use async/await and let tasks wait. Don't dedicate a thread to each waiting job.

5. A float that can't add 1

float big = 16_777_216f;

Console.WriteLine(big + 1 == big);
Console.WriteLine(0.1 + 0.2 == 0.3);
Console.WriteLine(0.1 + 0.2);

True
False
0.30000000000000004

16,777,216 is 2²⁴. A float has 24 bits of precision, so above that number it can only hold even integers. Adding 1 rounds straight back down:

16777216 -> 16777216
16777217 -> 16777216  (rounded)
16777218 -> 16777218
16777219 -> 16777220  (rounded)

And 0.1 has no exact binary representation, which is why 0.1 + 0.2 isn't 0.3 in C#, or in most languages.

decimal stores base-10 digits, so:

decimal a = 0.1m, b = 0.2m;

Console.WriteLine(a + b == 0.3m);

True

Useful at work: decimal for money. Never compare float/double with ==; compare with a tolerance.

Recap

int overflow is silent. Use checked where it matters.
Arrays cap at 2,147,483,591 elements, whatever your RAM.
Stack overflows can't be caught. Turn deep recursion into a loop.
Waiting is cheap with tasks, expensive with threads.
float and double approximate. decimal for money.

Try any of these on your machine and post your numbers in the comments. I'm curious how much they vary.

I make short, tested videos about C# and what happens when you push it. More on the Naze Code YouTube channel.

Sources: Microsoft Learn, Array.MaxLength, checked and unchecked, StackOverflowException. Tested on .NET 10.0.10 (SDK 10.0.302), Windows 11, Release build.

DEV Community: Naze Code

I measured the viral "talk like a caveman" token saver. A two-word prompt got most of it.

First: the headline number contradicts its own docs

Second: it is not a pile of prompt files

The test: a real bug, not a toy prompt

Result: the 65% is real, but it's a different mode

A detail nobody mentions: compression also cuts variance

The skill is not free

Proof: did the answers get worse?

The finding that isn't documented: it compresses shapes, not formats

Lossy to the model, lossless on disk

Verdict: should you install it?

I tried REA, the #1 trending repo on GitHub — can AI really reverse-engineer a .NET app?

What REA actually is

The test app: Naze Pixel

Test 1 — the normal .NET build

Test 2 — the obfuscated build

Test 3 — Native AOT (machine code)

So, real or hype?

The actual lesson for .NET developers

How big is Hello World in C#? From 76 MB down to 0.73 MB

1. Default: 0.16 MB, but it isn't the whole story

2. Self-contained: 76.63 MB, 191 files

3. Trimmed single file: 12.30 MB, one file

4. Native AOT: 1.06 MB, 7 ms

5. Native AOT tuned for size: 0.73 MB

Which one should you use?

Why LINQ is lazy: IEnumerable and yield in C#, explained by running it

1. Nothing runs until someone asks

2. What the compiler turns yield into

3. Infinite sequences and early stops

4. The argument check that runs too late

Recap

5 ways null gets past C# nullable reference types

1. The ! that only silences the compiler

2. JSON that doesn't read your annotations

3. Arrays start full of nulls

4. Generic T? that isn't nullable

5. The warning everyone scrolls past

Recap

What if the garbage collector never runs? 5 C# GC experiments

1. A hundred million objects of garbage

2. Keep everything

3. Turning the GC off

4. Small collection vs full collection

5. Calling GC.Collect() "to be safe"

Recap

C# records, structs and equality: what == really compares

1. Class vs record

2. A record holding a list

3. with makes a shallow copy

4. The struct whose Equals allocates

Recap

5 C# DateTime bugs that pass every test

1. Subtracting local times across a clock change

2. DateTime.Parse and the vanishing Z

3. == that ignores time zones

4. AddDays across a clock change

5. A test that depends on what day it is

Recap

Are exceptions really slow in C#? I threw a million to find out

1. What does one throw cost?

2. Does a try block cost anything if nothing throws?

3. Does it matter how deep the throw is?

4. int.Parse + catch vs int.TryParse

5. throw ex vs throw

Recap

What async/await really compiles to in C# (and when ValueTask is worth it)

1. What runs where, and in what order

2. The class (or struct) the compiler writes for you

3. The fast path: awaiting something that's already done

4. What each call costs

So when is ValueTask worth it?

Recap

5 ways Cancel doesn't actually cancel in C#

1. Passing the token to Task.Run and nowhere else

2. Taking a token and not passing it on

3. Stopping quietly instead of loudly

4. Catching the wrong exception type

5. A retry loop that retries cancellation

2. What the compiler turns `yield` into

1. The `!` that only silences the compiler

4. Generic `T?` that isn't nullable

5. Calling `GC.Collect()` "to be safe"

3. `with` makes a shallow copy

4. The struct whose `Equals` allocates

2. `DateTime.Parse` and the vanishing `Z`

3. `==` that ignores time zones

4. `AddDays` across a clock change

2. Does a `try` block cost anything if nothing throws?

4. `int.Parse` + catch vs `int.TryParse`

5. `throw ex` vs `throw`

So when is `ValueTask` worth it?

1. Passing the token to `Task.Run` and nowhere else

1. How high can an `int` count?