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