Definition of software bloat - see "Emacs" (veering off-topic) [LWN.net]

Definition of software bloat - see "Emacs" (veering off-topic)

Posted Feb 25, 2008 9:32 UTC (Mon) by rise (guest, #5045)
In reply to: Definition of software bloat - see "Emacs" (veering off-topic) by pr1268
Parent article: Emacs news: new maintainer, version 22 pretest

Interesting, I remember being shocked when I opened a multiple gigabyte log file in GNU emacs
with no issues approximately three years ago.  It took a little while to start up, but it
wasn't bad at all.  I can't recall if this was on a 64-bit processor or not, that might make a
difference.  In my experience emacs handles large files much better than programs like less.

Definition of software bloat - see "Emacs" (veering off-topic)

Posted Feb 25, 2008 21:43 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

64-bitness will definitely make a difference. This all has to do with the 
maximum size of Lisp integers (as used for things like the buffer 
position). Emacs uses a couple of high bits as tag markers (like many Lisp 
implementations), leaving you with enough to open a Gb or so on a 32-bit 
platform (maybe still 512Mb, I can't remember if the limit was ever 
lifted).

Emacs maximum buffer size

Posted Mar 6, 2008 17:34 UTC (Thu) by anton (subscriber, #25547) [Link] (1 responses)

Yes, I also guess that the buffer size limit comes from the limited word size combined with needing some bits for Lisp tags. I just made a few experiments:

Starting a 32-bit Emacs on a 159MB file: "Maximum buffer size exceeded".
Starting a 32-bit Emacs on a 127.1MB file: works, and that emacs then has a VSZ of 137MB and an RSS of 134MB.
Starting a 64-bit Emacs on an 784MB file: works.

Emacs maximum buffer size

Posted Mar 9, 2008 19:25 UTC (Sun) by nix (subscriber, #2304) [Link]

It's not a guess, it's a fact, and even a documented one :)

Perhaps it sucks a bit, but it's essentially irrelevant on 64-bit 
platforms unless Emacs starts to use a whole *lot* more bits for tags...