all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Andrea Corallo <akrl@sdf.org>
Cc: emacs-devel@gnu.org
Subject: Re: Pure space and overflow question
Date: Fri, 21 Feb 2020 16:16:29 +0200	[thread overview]
Message-ID: <838skwja9u.fsf@gnu.org> (raw)
In-Reply-To: <xjfy2sw2ggt.fsf@sdf.org> (message from Andrea Corallo on Fri, 21 Feb 2020 13:54:42 +0000)

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Feb 2020 13:54:42 +0000
> 
> > That said, why does your configuration require more pure space than
> > any other on that same platform?
> 
> Effectively in comp.c are allocate object that goes into pure space and
> all the code is under #ifdef HAVE_NATIVE_COMP.
> 
> Also the constant objects present in every compilation unit can have a
> small overhead respect to the elc one.  This is because they include the
> data used by the 'top_level_run' function.

Do you really need the former to be pure, and to be dumped in general?
If so, why?

I think with portable dumper in place, we should have a more
fine-grained distinction between the stuff that really needs to be
dumped, and stuff that just happens to be there due to code that runs
at loadup time.  The latter should not be dumped, but instead should
be re-created anew in every Emacs session.  In particular, stuff that
is needed for compilation should ideally not even be in memory until
the user wants to compile something.

Am I missing something?



  reply	other threads:[~2020-02-21 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 18:04 Pure space and overflow question Andrea Corallo
2020-02-20 19:56 ` Eli Zaretskii
2020-02-20 22:10   ` Andrea Corallo
2020-02-21 11:53   ` Andrea Corallo
2020-02-21 12:43     ` Eli Zaretskii
2020-02-21 13:54       ` Andrea Corallo
2020-02-21 14:16         ` Eli Zaretskii [this message]
2020-02-21 15:23           ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=838skwja9u.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=akrl@sdf.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.