>> Peak memory consumption is 1.3 MB. At this point you might want to stop reading and make a guess on how much memory a native code version of the same functionality would use.

At this point I'd make two observations:

- how big is the text file? I bet it's a megabyte, isn't it? Because the "naive" way to do it is to read the whole thing into memory.

- all these numbers are way too small to make meaningful distinctions. Come back when you have a gigabyte. It gets more interesting when the file doesn't fit into RAM at all.

The state of the art here is : https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... , wherein our hero finds the terrible combination of putting the whole file in a single string and then running strlen() on it for every character.

> all these numbers are way too small to make meaningful distinctions. Come back when you have a gigabyte.

I have to disagree. Bad performance is often a result of a death of a thousands cuts. This function might be one among countless similarly inefficient library calls, programs and so on.

If you're not putting a representative amount of data through the test, you have no idea if the resource usage you're seeing scales with the amount of data or is just a fixed overhead if the runtime.

> how big is the text file? I bet it's a megabyte, isn't it?

The edit in the article says ~1.5kb

Single page on many systems, which makes using mmap() for it even funnier.

Not to mention inefficient in memory use. I would have expected a mention of interning; using string-views is fine, but making it a view of 4kB cache pages is not really.

Though I believe the “naive” streaming read could very well be superior here.

"It only matters at scale" is how you end up with code that hoses mobile apps and embedded boards the moment somebody swaps in a file that is merely bigger than the toy input. These bugs start small. If the code slurps the whole input, staying under 1 GB is not proof of anything, it just means you have not hit the edge yet.

I suspect it'll be selective

> If the file is mmap'd, and the string view points into that, presumably decent performance depends on the page cache having those strings in RAM.

Not so much, because you only need some fraction of that memory when the program is actually running; the OS is free to evict it as soon as it needs the RAM for something else. Non-file-backed memory can only be evicted by swapping it out and that's way more expensive,

All major OSes (well Windows and macOS) do in-memory compression before swap, which is cheaper than evicting a file-backed page. But still slow, so you don't want to rely on it.