[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36649: 27.0.50; pure space and pdumper
From: |
Pip Cet |
Subject: |
bug#36649: 27.0.50; pure space and pdumper |
Date: |
Fri, 28 Aug 2020 12:32:10 +0000 |
On Sat, Aug 22, 2020 at 9:59 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Aug 22 2020, Pip Cet wrote:
> > +purecopy (Lisp_Object obj);
> >
> > DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
> > doc: /* Make a copy of object OBJ in pure storage.
>
> Perhaps purecopy should be dropped or made a no-op?
I believe that would be a logical next step, yes. The comment in
loadup.el says hash-consing saves "around 11% of pure space", which
sounds like it isn't worth the hassle to me.
So my suggestion would be to apply this patch first (removing the C
parts of pure space), then remove unexec, then turn purecopy into an
alias for identity and remove as many instances of it as possible.
Just as a reminder, we're still putting a 3 MB block of zero bytes
into every emacs binary...
Should this be discussed on emacs-devel? I've CC'd Andrea since I
believe the native-comp branch interacts with pure space in
complicated ways.
- bug#36649: 27.0.50; pure space and pdumper, Lars Ingebrigtsen, 2020/08/21
- bug#36649: 27.0.50; pure space and pdumper, Pip Cet, 2020/08/21
- bug#36649: 27.0.50; pure space and pdumper, Eli Zaretskii, 2020/08/21
- bug#36649: 27.0.50; pure space and pdumper, Andreas Schwab, 2020/08/21
- bug#36649: 27.0.50; pure space and pdumper, Paul Eggert, 2020/08/21
- bug#36649: 27.0.50; pure space and pdumper, Richard Stallman, 2020/08/21
- bug#36649: 27.0.50; pure space and pdumper, Pip Cet, 2020/08/22
- bug#36649: 27.0.50; pure space and pdumper, Andreas Schwab, 2020/08/22
- bug#36649: 27.0.50; pure space and pdumper,
Pip Cet <=
- bug#36649: 27.0.50; pure space and pdumper, Andrea Corallo, 2020/08/28
- bug#36649: 27.0.50; pure space and pdumper, Paul Eggert, 2020/08/22