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: Suppressing native compilation (short and long term) Date: Sun, 02 Oct 2022 08:57:13 +0300 Message-ID: <83sfk6ahty.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.fsf@gnu.org> <87mtafnun5.fsf@trouble.defaultvalue.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9604"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 07:58:35 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 1oerzn-0002Lg-DS for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 07:58:35 +0200 Original-Received: from localhost ([::1]:54372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oerzl-0008Mt-8f for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 01:58:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oerye-00079R-MC for emacs-devel@gnu.org; Sun, 02 Oct 2022 01:57:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37552) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeryd-0001Yk-IG; Sun, 02 Oct 2022 01:57:23 -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=eOmw8EVsRdOZWITCTIPTrBQgOEoCIw3emHnvfGdVNWw=; b=KNIx0YF1F5Nt Qo0VNcId4knf4+Gqrrt73vfaJKL9zGfHSeyDfiIU8BTCB7oddQfmEuk/T9HwT0zOmh2d5j1mxwUH0 iDnVd/ST/c1cUVBJX8Gzpa9aP31OQgTMqjlGuO3LFxx4WI+rariAvpKx2Zz39m2dICL2FlpPvF1up ZmmG2/RkY5H2sUQelOM1A2KabuAjH9cReuzovs1swF8PXG+ewsqivbTH8VPrDNMJ34FI6UuI4C8Ic zSPnmUcVsaR9J/29Y+yB63JosFYCB1EcwGfNqqZkDUtab/+56ldBElYv8ZQKOGAatnzvhO9Ey3OGT 4G45TScaP/8Tw5Q9HQpB9g==; Original-Received: from [87.69.77.57] (port=3472 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 1oeryc-0000UX-Ia; Sun, 02 Oct 2022 01:57:23 -0400 In-Reply-To: <87mtafnun5.fsf@trouble.defaultvalue.org> (message from Rob Browning on Sat, 01 Oct 2022 15:42:06 -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" Xref: news.gmane.io gmane.emacs.devel:296576 Archived-At: > From: Rob Browning > Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, > akrl@sdf.org > Date: Sat, 01 Oct 2022 15:42:06 -0500 > > My current expectation is that if it ends up being feasible, we'll > probably want to treat the package-related .eln files like the .elc > files, and build them during the package install. For example, > elpa-magit (the current magit add-on package) will want to generate both > the .elc and .eln files for all of its .el files when its turn comes > around during installs/upgrades. > > I say that because if it's a single-user machine and the user invokes > "apt install elpa-magit", I'd imagine they're doing that because they > want to use magit, in which case it doesn't hurt to get the work out of > the way up-front, and it might help in that all the work will be > finished at once, so they won't incur costs (battery-consumption, etc.) > later, when they might not expect or want it. (Not a critical issue, > possibly, but perhaps friendlier.) > > And if it's a multi-user machine, with a lot of emacs users, at the > moment I don't see any reason to want to compile the same file 50 times > for 50 users (or even more than just once), incurring the attendant > power and storage costs. I don't think you should try to second-guess the user who installs a package. They could just want to study the sources, for example. The native compilation is implemented as JIT capability for a reason. We dicussed the various aspects of that for a long time before deciding on what you see today. My advice is not to reject that without very good reasons (and those reasons should probably be communicated to us when found), just because of some analogy with byte compilation, as that analogy breaks on several levels. By using native compilation in its default JIT manner, you are basically using Emacs as the upstream project meant it to be used, which means, among others, that you don't need to fight an uphill battle against various defaults and discover situations that no one expected to happen. The reasons which you mention in favor of AOT native compilation don't sound serious enough: I see no problem in having the compilation happen only when it's needed in those cases. Battery consumption doesn't seem very relevant, because JIT compilation will happen when the system is used, not when it sleeps. And it is entirely not guaranteed that by compiling everything you will save power in the long run, because there are good chances you will be compiling stuff that won't be used for a long time. Without quantitative data of long-term power usage on which to base the conclusions, I don't see why you should a-priori assume that compiling everything from the get-go should use less power. Same goes for disk space by multiple users. All in all, I think JIT compilation strikes a good balance between resources and their actual usage. This also matches my personal experience of using Emacs 28 with native compilation since day one: I never had to look back on the decision not to use AOT compilation of everything. Of course, this is eventually your call. But my recommendation is to try to stick to the default behavior unless it causes actual (as opposed to imaginary or presumed) problems, based on actual usage.