[ZeroConcerns]

Ah, yes, exactly the pointless diversion I needed for my lunch break. For science: generating a C# switch statement for similar purposes took 7 minutes on similar-ish hardware, but the resulting 99.2GB file could not be opened or compiled ('Stream is too long'), which was slightly disappointing.

Optimization efforts included increasing the internal buffer size of the StreamWriter used to create the source code: this reduced the runtime to around 6 minutes, as well as running a non-debug build, as it was observed that the poor Visual Studio metrics gathering process was contributing significantly to disk activity as well, but that ultimately didn't matter much. So, ehhm, yes, good job on that I guess?

[afandian]

Isn't the obvious thing to generate different classes for different ranges over the input? Then the classes could be loaded lazily.

And if you then make the ranges tree-shaped you get logarithmic complexity, which massively cuts down the O(n) of the rather naive chained `if` statements.

[jiggawatts]

To match the article, you'd want to directly emit the Intermediate Language (IL) tokens with something like this: https://learn.microsoft.com/en-us/dotnet/api/system.reflecti...

I haven't found any authoritative source, but I strongly suspect that the .NET bytecode format has 32-bit limits all over the place. Maaaybe you could break up the code into functions less than 1 GB in size and then chain them together.

[opticfluorine]

I wonder if you could generate it via a Roslyn incremental source generator instead of as a file to bypass this limit. I'm guessing not, but it does sound like fun.

[tkapin]

You can totally use source generators for that.

[xnorswap]

You're only allowed up to 65535 locals, but this includes hidden locals, which the compiler adds if you're compiling in debug mode.

So you have to make sure to compile only in release mode just to get to 16 bits.

[szundi]

Diversion for your whole next week: just generate machine code binary for this