• lowleveldata@programming.dev
    link
    fedilink
    English
    arrow-up
    21
    ·
    22 hours ago

    One user reported it chewing through around 500MB of RAM on 64-bit Windows 7

    It says this right in the article. Is reading the article too much to ask?

    • tal@lemmy.today
      link
      fedilink
      English
      arrow-up
      26
      ·
      21 hours ago

      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.

      • ChaoticNeutralCzech@feddit.org
        link
        fedilink
        English
        arrow-up
        11
        ·
        20 hours ago

        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).