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: Add a configure option for NATIVE_FULL_AOT? Date: Tue, 17 Aug 2021 20:01:56 +0300 Message-ID: <83zgtg57jv.fsf@gnu.org> References: <83bl5w70vw.fsf@gnu.org> <834kbo6xm5.fsf@gnu.org> <87zgtg3x4i.fsf@wavexx.thregr.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34356"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Yuri D'Elia Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 17 19:03:05 2021 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 1mG2US-0008iV-Uy for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Aug 2021 19:03:04 +0200 Original-Received: from localhost ([::1]:36264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mG2UQ-00050p-Um for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Aug 2021 13:03:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37950) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mG2TS-0004Ev-19 for emacs-devel@gnu.org; Tue, 17 Aug 2021 13:02:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37678) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mG2TQ-0006GI-SX; Tue, 17 Aug 2021 13:02:01 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2308 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 1mG2TQ-0006gt-F1; Tue, 17 Aug 2021 13:02:00 -0400 In-Reply-To: <87zgtg3x4i.fsf@wavexx.thregr.org> (message from Yuri D'Elia on Tue, 17 Aug 2021 17:32:29 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:272503 Archived-At: > From: Yuri D'Elia > Date: Tue, 17 Aug 2021 17:32:29 +0200 > > > No, only the users who need a file FOO.eln will compile it and have it > > in their eln-cache. > > I run emacs in a server environment under different users regularly, and > I consider this a drawback. > > >> The motivation is to compile and install these files once system-wide, > >> instead of duplicating them in all users' directories. Conceptually they > >> aren't user specific but belong to the Emacs package. > > > > That's... not how this was intended to work. > > > > I wonder if anyone else has an opinion here. > > As soon as I discovered NATIVE_FULL_AOT, I've been using it. JIT is > nice, but it's relatively easy to trigger. Even if that's async, it's > quite noticeable. > > I personally prefer to pay the AOT price in disk space just from a > latency perspective. Which is actually a space saving anyway, in a > multiuser system. > > And speaking of opinions, I'd also wish the eln-cache would be stored in > an opportune xdg path when an xdg config is being used ;) Well, then it's a pity you are speaking up just now, instead of 8 months ago, or whenever you discovered NATIVE_FULL_AOT. We've spent these months discovering non-trivial problems with the way Emacs is built by default with natively-compiled Lisp, fixing those problems, and stabilizing the solutions so that Emacs could go into pretest soon. If we now change things under the assumption that NATIVE_FULL_AOT will be used frequently, let alone by default, we'll have to redo some of this work, or risk releasing Emacs with potential build, installation, and usage problems. I'm not even sure we have infrastructure and user commands to support this paradigm. For example, what do you do if all the Lisp files in Emacs are natively-compiled AOT, and you then modify one of the *.el files? With JIT compilation, the new .el file will be automatically compiled behind the scenes when first loaded. With all of them compiled AOT, you will now have an outdated .eln file in the standard place and a new one in your eln-cache, which will definitely confuse or bite you some day. The XDG thing was discussed and we decided not to do that. Again, perhaps if you and others spoke back then, maybe we would make a different decision. That is why people are generally encouraged to bring up issues as soon as they discover them and not much later -- so that we could fix them in time for the next release, and be sure we solve any fallout.