this post was submitted on 04 Jul 2026
296 points (97.7% liked)

PC Master Race

21632 readers
891 users here now

A community for PC Master Race.

Rules:

  1. No bigotry: Including racism, sexism, homophobia, transphobia, or xenophobia. Code of Conduct.
  2. Be respectful. Everyone should feel welcome here.
  3. No NSFW content.
  4. No Ads / Spamming.
  5. Be thoughtful and helpful: especially when new beginners have questions.

founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] tal@lemmy.today 24 points 13 hours ago (1 children)

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.

They do, in the linked GitHub issue:
https://github.com/PlummersSoftwareLLC/TinyRetroPad/issues/21

Apparently, that's just sitting idle.

By not optimizing for file size with Crinkler, the executable grows by a factor of 4 and RAM usage shrinks by a factor of 300. This build will probably be made available to people who value 500 MB RAM per running instance more than the 9 kiB of disk space saved (I assume that's anyone wanting to use it in practice).