Re: BASE_PURESIZE

[Dan Nicolaescu <dann@ics.uci.edu>]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Andreas Schwab <schwab@linux-m68k.org>
  > > Cc: emacs-devel@gnu.org
  > > Date: Sat, 24 Oct 2009 12:37:19 +0200
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > > > For the record, the extra use of purecopy caused the pure_bytes_used
  > > > value to go up by 52KB on 32-bit Windows, and by 92KB on 64-bit
  > > > GNU/Linux.  So it looks like the ratio is actually closer to 9/5 than
  > > > to either the old 10/6 or the new 11/7.  Or maybe I'm missing
  > > > something.
  > > 
  > > It all depends on the ratio of string data vs. lisp object pure storage.
  > 
  > I made some measurements.  The ratio of 11/7 seems to work pretty
  > well, but there are two additional problems:
  > 
  >  . The default value of SYSTEM_PURESIZE_EXTRA is zero, and is not
  >    increased for GUI builds.  This causes a --without-x build to waste
  >    some 100KB.  If we want to handle this, the basic constant in
  >    BASE_PURESIZE can be as low as 1290000 and SYSTEM_PURESIZE_EXTRA
  >    should have its default at 140000 for GUI builds, zero otherwise.
  > 
  >  . The amount of pure storage used by load-history depends on the
  >    length of the filename of the directory where Emacs is dumped.  In
  >    my case, I have 32 characters before the "emacs/lisp/" part, so I'm
  >    guessing that's the main reason the value of 1430000 was too small
  >    for me.

We have 2 more problems with load-history: although in loadup.el is
purecopied, something still seems to maintain references to the file
name strings, they are still present as non-pure strings in the dumped
image both as absolute file names and as the arguments passed to load
(see the simple patch I posted yesterday to dump strings).  So we are
still wasting memory on those.

It would be great if load-history would be constructed in pure memory
from the beginning when dumping (instead of purecopying later).
Maybe someone that understands that code could do that...

  > We could decide that we don't care too much about the --without-x

IMHO --without-x is completely unimportant.