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: Loading tramp for dump goes into infinite regress Date: Mon, 25 Jul 2022 16:56:06 +0300 Message-ID: <83r129e1op.fsf@gnu.org> References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13961"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael.albinus@gmx.de, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 25 15:57:51 2022 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 1oFyak-0003UQ-Sn for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 15:57:50 +0200 Original-Received: from localhost ([::1]:56086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFyaj-0002de-Dz for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 09:57:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFyZ4-0000m5-NW for emacs-devel@gnu.org; Mon, 25 Jul 2022 09:56:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48386) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFyZ4-000708-Dr; Mon, 25 Jul 2022 09:56:06 -0400 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=GUFvICt+prYCanmaJz21jmZ/+tKT6lRDmFE/koXy/sk=; b=BPTS9OQdaDFB DQcdALH73aUtgZqE/ZXHuFxZO79m6CONaqofIt1ysIRgnu0ci+CE8cnWiv1kDX7jVOgGnLUOsboA3 U2LAjwqABGK8rA7CEim2W33MIoCnTKnqwKty6MPtpF/ffFe8WdTh7B8HZeEVVA2jLVhmOoHCFWDgY K6i1aGtmLvkYnXODCEGfbWufih1G4DgwtZzyp8ia9Kmi7ZC/Bu9fyyKUXvmNPZQKUkD5rLFuH1q7+ n7sk+mUaw8U+ojaiFjmqvUw3mQUZ8aZVzMYdc1IVz2wfTKhzXOr7etrhEEOT/z+hViSktBJq/i/WR Er4SpCNlAE3Pzh8tBoA6xQ==; Original-Received: from [87.69.77.57] (port=2235 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 1oFyZ3-0006a7-TA; Mon, 25 Jul 2022 09:56:06 -0400 In-Reply-To: (message from Lynn Winebarger on Mon, 25 Jul 2022 08:49:27 -0400) 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" Xref: news.gmane.io gmane.emacs.devel:292632 Archived-At: > From: Lynn Winebarger > Date: Mon, 25 Jul 2022 08:49:27 -0400 > Cc: michael.albinus@gmx.de, emacs-devel > > > > it seems like something undesirable is going on between dumping and > > > the native compilation unit. > > > > I find this hard to believe. > > If I can recreate it in a more direct way on my personal machines, I'll put in a bug with details including the > required modifications to tramp.el (to remove the problematic require of tramp-loaddefs). Please do. > > Btw, you are aware that dumping *.eln files basically dumps just their > > names, not their code? And that, when you start Emacs after dumping, > > it will load all of those *.eln files one by one, which takes time > > (*.eln files are just shared libraries, like *.so files), and use up > > shared-library and handle slots of the Emacs process? So I'm not even > > sure doing this would make sense from the performance POV: it could be > > that startup will slower, not faster. > > I am aware that dumping the eln files produces an indirection to the shared library, but not the details of the > implementation. > I would expect (or at least hope) that the effect of the evaluation that is done on loading to be stored in the > dump and for the shared libraries to get loaded into the process without repeating the evaluation. So things > like the order of customization groups should be fixed. It depends on the top-level forms of the package, and what they do. If they change values of variables, those values will be dumped, yes. > I would also expect that whatever the effect is on the emacs process with .eln files loaded by the dumped > file, it is no worse than it would be if loaded as part of my .emacs file. How is this different from the previous expectation of yours? > Another benefit I expect from native-compilation, dumped or not, is more efficient memory use when running > multiple emacs processes. With dumping, I would expect (or hope for) better garbage collector behavior > since the amount of allocation required for the loaded modules should be pre-determined (whether byte- or > native-compiled). If the image is 300MB (including the shared libraries), so be it, as long as the memory is > shared between multiple processes. I don't think I understand this expectation, and I don't think natively-compiled code has any advantages wrt GC over the byte-compiled code. > I'd also like a baseline expectation of performance with native-compiled libraries in the dumped image. What kind of performance? > > In any case, I'd suggest to get this working with *.elc files in a > > build without native compilation support, before you try it with > > native compilation. > > First I'll see if I can get the ordering straightened out with just the core emacs files required by these > packages, then do a test between byte-compiled and native-compiled on those. I'm saying that your job could be easier if you did the first step with byte-compiled files.