4 ms·

Interesting. So that's why emacs whigs out sometimes when trying to open very large files: because it has a recursive GC that has trouble when it runs out of st

Interesting. So that's why emacs whigs out sometimes when trying to open very large files: because it has a recursive GC that has trouble when it runs out of stack space. Assuming I read the first statement correctly. Seems like a welcome change. I'm not too well versed with the internals, but does 4.6MB seem reasonable for a memory footprint? I mean, compared to Slack, not bad. > The naive version of this scheme needs about 4.6MB of overhead on my current 20MB Emacs heap, but it should be possible to reduce the overhead significantly by taking advantage of the block allocation we do for conses and other types --- we can put whole blocks on the queue instead of pointers to individual block parts, so we can get away with a much smaller queue.

harrygeez 9y ago
Not to be rude but Electron apps' level of footprint has always been a compromise and should not be used to justify extraneous resource usage. Emacs must be able to run from the console and resource-constrained systems like AWS instances, where 5mb of RAM can make a difference.
- AceJohnny2 9y ago
  Remember when people joked that EMACS stood for "Eats Memory And CPU Superbly?" And then each generation reinvents its state-of-the-art abstracted memory hog... Edit: more jokes, from 1985: https://github.com/sbp/lemacs/blob/master/etc/emacs.names https://github.com/sbp/lemacs/blob/master/etc/emacs.names
  - s_kilk 9y ago
    Eight Megs And Constantly Swapping
    - kazinator 9y ago
      Precisely relevant to the issue at hand: Eight Megs Ain't Comfortable Stack
- craftkiller 9y ago
  If 5mb of ram makes the difference wouldn't that be the time to try mg[1] or edit remotely using tramp? Certainly agree that Electron should not be used as a justification. [1] https://en.wikipedia.org/wiki/Mg_(editor) https://en.wikipedia.org/wiki/Mg_(editor)
  - defgeneric 9y ago
    As of late I've been using `emacs --daemon=some-name` on instances. I attach with `emacs-client -s some-name -t` after I ssh in and detach with `C-x 5-0`. Sometimes I'll run multiple named emacs daemons. This has worked really well to keep persistent independent workspaces on remote instances. Tramp was always a headache and running emacs in screen tends to introduce terminal color and keybinding problems.
  - nerdponx 9y ago
    How does mg differ from Emacs proper?
    - msds 9y ago
      It's a text editor, not a lisp environment that edits text. I once had a decent amount of fun splicing it with Lua, before deciding that I don't actually care about text editors...
- cwyers 9y ago
  https://www.gnu.org/software/emacs/manual/html_node/emacs/Remote-Files.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...
coldacid 9y ago
An additional overhead between 20% and 25% definitely doesn't feel reasonable to me. Hopefully this isn't linear.
- greglindahl 9y ago
  It must strongly depend on what you've got activated; when I edit multi-gigabyte files I start up with '-q' so my init file doesn't turn on FlySpell.
- quotemstr 9y ago
  It's not reasonable to me either. That's the naive version. :-) There are various tricks for reducing the overhead to insignificance.
pulisse 9y ago
So that's why emacs whigs out sometimes when trying to open very large files: because it has a recursive GC that has trouble when it runs out of stack space. Assuming I read the first statement correctly. That doesn't seem right to me. (a) In emacs a file's contents aren't stored in a deeply nested structure, no matter what the size. It's a gap buffer. (b) Structure aside, that buffer isn't a Lisp object, but an object internal to the C level, so not subject to GC. And note that Emacs's large file behavior isn't especially different than other non-minimalist editors[1]. https://github.com/jhallen/joes-sandbox/tree/master/editor-perf#time-to-load-3-gb-file-insert-character-at-start-and-exit https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
pulisse 9y ago
If you read further in the thread you'll see that Stefan Monnier pointed out that using a stack instead of a queue for the objects would consume less memory than the current GC implementation.

harrygeez 9y ago

Not to be rude but Electron apps' level of footprint has always been a compromise and should not be used to justify extraneous resource usage. Emacs must be able to run from the console and resource-constrained systems like AWS instances, where 5mb of RAM can make a difference.

AceJohnny2 9y ago
Remember when people joked that EMACS stood for "Eats Memory And CPU Superbly?" And then each generation reinvents its state-of-the-art abstracted memory hog... Edit: more jokes, from 1985: https://github.com/sbp/lemacs/blob/master/etc/emacs.names https://github.com/sbp/lemacs/blob/master/etc/emacs.names
- s_kilk 9y ago
  Eight Megs And Constantly Swapping
  - kazinator 9y ago
    Precisely relevant to the issue at hand: Eight Megs Ain't Comfortable Stack
craftkiller 9y ago
If 5mb of ram makes the difference wouldn't that be the time to try mg[1] or edit remotely using tramp? Certainly agree that Electron should not be used as a justification. [1] https://en.wikipedia.org/wiki/Mg_(editor) https://en.wikipedia.org/wiki/Mg_(editor)
- defgeneric 9y ago
  As of late I've been using `emacs --daemon=some-name` on instances. I attach with `emacs-client -s some-name -t` after I ssh in and detach with `C-x 5-0`. Sometimes I'll run multiple named emacs daemons. This has worked really well to keep persistent independent workspaces on remote instances. Tramp was always a headache and running emacs in screen tends to introduce terminal color and keybinding problems.
- nerdponx 9y ago
  How does mg differ from Emacs proper?
  - msds 9y ago
    It's a text editor, not a lisp environment that edits text. I once had a decent amount of fun splicing it with Lua, before deciding that I don't actually care about text editors...
cwyers 9y ago
https://www.gnu.org/software/emacs/manual/html_node/emacs/Remote-Files.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...

coldacid 9y ago

An additional overhead between 20% and 25% definitely doesn't feel reasonable to me. Hopefully this isn't linear.

greglindahl 9y ago
It must strongly depend on what you've got activated; when I edit multi-gigabyte files I start up with '-q' so my init file doesn't turn on FlySpell.
quotemstr 9y ago
It's not reasonable to me either. That's the naive version. :-) There are various tricks for reducing the overhead to insignificance.

pulisse 9y ago

So that's why emacs whigs out sometimes when trying to open very large files: because it has a recursive GC that has trouble when it runs out of stack space. Assuming I read the first statement correctly. That doesn't seem right to me. (a) In emacs a file's contents aren't stored in a deeply nested structure, no matter what the size. It's a gap buffer. (b) Structure aside, that buffer isn't a Lisp object, but an object internal to the C level, so not subject to GC. And note that Emacs's large file behavior isn't especially different than other non-minimalist editors[1]. https://github.com/jhallen/joes-sandbox/tree/master/editor-perf#time-to-load-3-gb-file-insert-character-at-start-and-exit https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

pulisse 9y ago

If you read further in the thread you'll see that Stefan Monnier pointed out that using a stack instead of a queue for the objects would consume less memory than the current GC implementation.