Hacker News Reader

Comment by mav3r1ck | Hacker News Reader

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.

View on HN

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

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.

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

Eight Megs And Constantly Swapping

Precisely relevant to the issue at hand:

Eight Megs Ain't Comfortable Stack

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)

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.

How does mg differ from Emacs proper?

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

https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...

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

It's not reasonable to me either. That's the naive version. :-) There are various tricks for reducing the overhead to insignificance.

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.

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.

Reply on news.ycombinator.com