Re: Pure space

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 17 Aug 2024 08:57:46 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: emacs-devel@gnu.org
> 
> > Btw, I get the impression that help facilities generate plenty of large
> > strings that are ultimately dumped, so it would be useful to measure the
> > size of pure space with and without the string deduplication
> > optimization enabled, and decide whether it would be worth preserving in
> > some form.
> 
> It's already disabled in scratch/igc (when HAVE_MPS is set), and IIRC I
> didn't have to increase the pure space size...

That's okay, because it isn't "removing pure space", and it is on a
feature branch which was not yet landed.  So we have enough time to
consider what to do with it until it becomes actually relevant.

> Keep in mind that the current implementation only works one way: if we
> dump "c", then "abc", both strings will be copied to pure space
> completely. If we dump "abc", then "c", the second string will be
> deduplicated to point at "abc" + 2.  I suspect this is the opposite of
> what we need.
> 
> So it might be fairer to fix that first, and compare then. However,
> once we start implementing rudimentary data compression for dumps, where
> do we stop?

Once again, the only way towards removing pure space is to decide that
we drop support for platforms where Emacs can only be built with
unexec.  If there's consensus about dropping the unexec-only
platforms, we can move towards removing pure; otherwise we cannot.