this post was submitted on 04 Jul 2026
368 points (98.2% liked)

PC Master Race

21643 readers
1027 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
[–] CameronDev@programming.dev 10 points 1 day ago* (last edited 23 hours ago) (4 children)

Size on disk doesn't correlate to memory usage or load time. You can get a very small on disk size by compression, or downloading the main executable at runtime.

[–] JackbyDev@programming.dev 1 points 14 hours ago

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

[–] Feyd@programming.dev 8 points 1 day ago* (last edited 1 day ago) (1 children)

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.

[–] CameronDev@programming.dev 2 points 23 hours ago

Even the linked libraries may not contribute anything, if they are already loaded and shared amongst other processes. There are so many factors and trade offs that you cant really make any assumptions based off just the executable size.

[–] BCsven@lemmy.ca 7 points 1 day ago (1 children)

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

[–] CameronDev@programming.dev 3 points 23 hours ago (1 children)

Once you start optimizing for one aspect, others become less important. In this case, they are doing a few hacks to get to 2.5kb, which do impact runtime performance. A few users report it using 500mb at runtime due to the compression :/

[–] BCsven@lemmy.ca 3 points 15 hours ago

Well that sucks, although I assume that's way better than the AI bloated version that now comes with Windows.

[–] ch00f@lemmy.world 7 points 1 day ago (4 children)

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.

[–] JigglySackles@lemmy.world 1 points 2 hours ago

.kkrieger was so damn cool. Mad impressive what they managed.

[–] ChaoticNeutralCzech@feddit.org 4 points 19 hours ago* (last edited 19 hours ago)

Simply building without Crinkler compression changes the file size to 11 kiB and RAM usage to 1.7 MB. That's almost double what Microsoft's old Notepad (at a file size of 250-350 kiB, including an uncompressed multi-size RGBA icon of around 100 kiB and localization) uses but not bad, and probably the version most people will prefer for practical use.

[–] CameronDev@programming.dev 7 points 23 hours ago

It does some of the tricks that .kkreiger uses, including compressing the binary.

And at least according to a few reports, it uses 500MB of ram:

https://github.com/PlummersSoftwareLLC/TinyRetroPad/issues/21

[–] LeFrog@discuss.tchncs.de 3 points 22 hours ago* (last edited 22 hours ago)

.kkrieger

Oh my god thanks for these memories

demoscene & 64K intro