They don't say the scenario where that's happening, though. Unless your editor supports large file editing, a mode where it doesn't load the whole file into memory, unless it has filesize restrictions that make it just fail, if you throw a large enough file at it, it's invariably going to use a bunch of memory.

$ dd if=/dev/zero of=out.bin bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 0.100949 s, 5.2 GB/s
$ vim out.bin

On my system, after it (slowly) finishes opening that file, vim's using 511MB RSS. I know that vim has some sort of large file editing support, though not how to use it.

On emacs, large file editing support is from the vlf package.

$ emacs
M-x vlf RET
out.bin RET

Emacs is using 75.3 MB RSS after opening that.

Yes apparently. Apologies.

Thinking it doesn't correlate at all seems foolish. There is some correlation, it's just miniscule.

The size of the main binary and all the libraries loaded does determine the starting point of the memory usage, but then doing things like loading files are going to also use memory and there are many strategies for optimizing for speed, memory usage, disk size that have tradeoffs between them. Anyway the point is that the size of the program itself isn't irrelevant even though it isn't the only factor in memory usage.

The premise is probably if you can optimize the code to be small, you are probably also optimizing how it runs too. Rather then just bloat up everything

Sure. I wasn't thinking of something like .kkreiger. I assumed that a small simple text editor would use a similarly small amount of memory. Shocked it ballooned so big. Sorry can't read the article at the moment.