From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Sun, 05 Feb 2023 09:40:24 +0200 Message-ID: <83r0v4sgpj.fsf@gnu.org> References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <83k0145guk.fsf@gnu.org> <835ychtcq9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26312"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Lynn Winebarger , Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 05 08:41:01 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pOZe0-0006eo-JA for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Feb 2023 08:41:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOZdN-00036x-BX; Sun, 05 Feb 2023 02:40:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOZdL-00036p-TN for emacs-devel@gnu.org; Sun, 05 Feb 2023 02:40:19 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOZdL-0008Ho-8G; Sun, 05 Feb 2023 02:40:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XLIk2N+PkASGVenE7ZoNDRDUNl1IrVWNwwq63Fil/Eo=; b=LuwDhr61mBjn ATzoU80xyRnGAukpekMDIS9M1dgP8uRX/lYMk/84B73/AagKyyiRxUDScbkGCDpK4aVkcP9oayqLo mo4LMqw9u3e75v+jVxmv1/VthgphEIgXQa+eFV28/0NMw316Dbh426xuYXkpmPrps5WNfOjoXp9rM yVqeMWGPZWGKUah4c0axQ4KXmSgB0nn8EDMxELgsCr8Hc+7wsPXEXjNiRvSvJR0GZgHple2kVA6PL At4q7qR7Fv9tnrqB8WBdAXeC0eDx68JvtSrpQlgQmo3nfA9kNr3DxPsI6raaC5oti3N5abHp34gQ1 MRF8J4Yj2pKBKt1fP6CvIg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOZdI-0006Mu-Gf; Sun, 05 Feb 2023 02:40:19 -0500 In-Reply-To: (message from Lynn Winebarger on Sat, 4 Feb 2023 17:05:19 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302994 Archived-At: > From: Lynn Winebarger > Date: Sat, 4 Feb 2023 17:05:19 -0500 > Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > On Sat, Feb 4, 2023 at 3:08 PM Eli Zaretskii wrote: > > > > > Something in emacs is putting advice on call-interactively. When I > > > extended the baseline dump to include essentially all libraries > > > included with emacs with native-compilation, it caused an infinite > > > (asynchronous) regress while compiling the trampoline for > > > call-interactively. I wasn't aware of this until /tmp filled up. > > > > Is this with Emacs 28 or Emacs 29? > > This was with 28.1 modified to support dumping with many pre-loaded > native-compiled files. I asked because Emacs 29 adds some changes specifically intended to solve the problem of infinite recursion in trampoline compilation. > As far as I know, emacs still doesn't support dumping arbitrary > native-compiled libraries at compile-time. What problems do you see if you try? AFAIR, if you tweak native-comp-eln-load-path so that the *.eln files you want to dump are directed to the ../native-lisp directory relative to where the Emacs binary lives, then dump Emacs, loading such a dumped Emacs should work. Andrea, am I missing something? > Which is too bad, because the dumped version is a LOT faster to > startup. Are you sure? is this with native-compilation or without it? > As per the other recent thread (3x increase in startup time), > loading eln files seems to be considerably slower than loading elc > files at startup, but in dumped images the difference is probably > the other way around. I don't see why it would be faster when loading a dumped Emacs: the pdumper file records only the names of the *.eln files, not their contents, so Emacs still has to load all of the *.eln files recorded in the pdumper file, and that takes time and doesn't change much when the names are recorded in emacs.pdmp. > I've > since approximated that dump with a byte-compiled version and the user > function dump-emacs-portable, but then I have to install before-init > hooks to systematically replace occurences of the user name and home > directory in variables and customizations to make the dump usable. > It's a kludge no distro would want to use. Even then there are a > handful of libraries that have to be kept out of the dump (using bogus > "(provide )" expressions) and then explicitly loaded in an > after-init hook after removing the bogus features. And they aren't > consistent with the ones that were problems for native-compiled > dumping. But my point is, loading that byte-compiled dump takes > somewhat longer than loading the native-compiled dump that had twice > as many pre-loaded libraries. If you want to dump more libraries than Emacs does by default, why not modify loadup.el to load those libraries at build time? Then they will be dumped together with all the rest, and the loading won't need any changes on your side. > Emacs needs a lot more work to really support compile-time dumping of > a larger set of libraries. There are too many instances of code > evaluated at load time that should be evaluated in a before-init or > after-init hook, that depend on variables set in C code after the dump > file is loaded. Or run-time services like dbus. To really support > site-specific dumping, a robust analysis identifying that code and > transforming it appropriately would have to be performed either prior > to or as part of dump-mode. It's non-trivial. The changes to the C > code to deal with additional objects like text properties while > purifying are (or were) trivial by comparison. I guess this is true, at least to some degree. Patches to this effect are welcome.