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.help Subject: Re: [External] : Re: Native compilation Date: Tue, 11 Jan 2022 19:04:20 +0200 Message-ID: <83pmoy6w6j.fsf@gnu.org> References: <875yr5up38.fsf@zoho.eu> <83k0flge7s.fsf@gnu.org> <87tuept0qc.fsf@zoho.eu> <83ee5tgcwv.fsf@gnu.org> <87ilv5sz9s.fsf@zoho.eu> <834k6ohp2o.fsf@gnu.org> <87ilutv5sb.fsf@zoho.eu> <83czl12xgd.fsf@gnu.org> <87tuebsp1b.fsf@zoho.eu> <831r1fa37q.fsf@gnu.org> <87czkys94w.fsf@zoho.eu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5093"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 11 18:14:00 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1n7Kie-0001DW-6Y for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Jan 2022 18:14:00 +0100 Original-Received: from localhost ([::1]:40102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7Kib-0006TJ-UJ for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Jan 2022 12:13:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7KZd-0000AX-0z for help-gnu-emacs@gnu.org; Tue, 11 Jan 2022 12:04:41 -0500 Original-Received: from [2001:470:142:3::e] (port=52144 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7KZc-000667-KD for help-gnu-emacs@gnu.org; Tue, 11 Jan 2022 12:04:40 -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=htVHVrW/d3ihCFnv5XgEyyKSL9tyzGbFwpTNbzdCT7o=; b=CRrwGpEHf7/n EGoDSrg3tStzrhq5Wy462gOK0lj8LvuwMlOTtbNMzlaUVNDldKtWB7m54iVNjJluP5yX6WZfFm6tc gJ98JWcL21sIp9Frxh7MqVOlf1GhbDBVW9JETuf2nfPE10YfZ/9wOVy/yv2InMxH6uXVu8DjgWRIB pQbvmjUiBJ2oZFuYD+FQ7TCfVDWA/e7hu+ST0jGrjiUaxw2K///JbOI5SmZSdHFpTDsvnPHm876pU aS519d4EeuwpVq2I6dkTE2+X5GVLIYo/foJw7wOoyMR2xOBIl3eHUorTqy+SPBMvbukgih+TLpzDJ Q0nA1g62GMv7pq0ruEdbRA==; Original-Received: from [87.69.77.57] (port=4639 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 1n7KZO-0003yZ-Vs for help-gnu-emacs@gnu.org; Tue, 11 Jan 2022 12:04:40 -0500 In-Reply-To: <87czkys94w.fsf@zoho.eu> (message from Emanuel Berg via Users list for the GNU Emacs text editor on Tue, 11 Jan 2022 14:18:55 +0100) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:135209 Archived-At: > Date: Tue, 11 Jan 2022 14:18:55 +0100 > From: Emanuel Berg via Users list for the GNU Emacs text editor > > Eli Zaretskii wrote: > > >>>> Thanks, you mean not to compile it natively or not compile > >>>> it at all? > >>> > >>> Natively. > >> > >> Okay, it is interesting that you say so because didn't you > >> use (?) to say that byte-compiling of the .emacs and > >> supplemental files was disencouraged? > > > > I did, but how is that relevant to the issue at hand? > > Because I would like to know if this new (?) attitude to a new > thing - is that actually a new attitude, or is it an old > attitude ("don't byte-compile your own Elisp") applied to > a new thing? (native byte-compilation) It is both. I see little sense in compiling init files (except as a method of finding bugs in them, which means you compile them and then throw away the .elc files). I see even less sense in natively compiling them: you get all the "issues" caused by natively-compiled ELisp, without any benefits. So it's a net loss. It follows that our advice to users should be not to do something that results in net loss for them. > Or, if it indeed is a new attitude, what is the basis of > that attitude? Natively-compiling Lisp files needs to make sure they are self-contained, i.e. they don't depend on other Lisp files that are not explicitly 'load'ed or 'require'd in them. Otherwise you will have warnings and errors during JIT native-compilation. Natively-compiling Lisp files also means you'll need to have the original Lisp files around, or else Emacs will refuse to load the .eln file. If you compress the source file, you need to have Emacs built with decompression support (zlib), otherwise Emacs will refuse to load the .eln file, claiming that the source isn't available. Replacing the .eln file that is loaded into a running Emacs session is "tricky" at best, because the *.eln files are actually shared libraries in disguise, and your typical OS doesn't like it very much when you delete a shared library that's in use. Etc. etc. -- using the *.eln files comes at a price, so paying that price when you get nothing in terms of performance is un-economical. So my advice is not to do that. > > Because the gains will be null and void. > > OK, so that's the basis, but then I again ask, why are there > gains doing this to the GNU Emacs (vanilla Emacs) Elisp, but > not to the local (HOME) Elisp? Because most of the code in a typical init file doesn't perform any significant processing that can be sped up by natively-compiling it. > Right, it doesn't look like it, either. So how do you natively > byte-compile the file x.el? By using one or more of special commands designed for that. > >> That happens automatically when Emacs is run, after being > >> configured --with-native-compilation [1], and it only > >> affects GNU Emacs Elisp, right? > > > > What is "that" in this case? > > Native byte-compilation of GNU Emacs (vanilla Emacs) Elisp. It happens automatically when Emacs loads a .elc file whose .el file can be found in the usual places, yes. > >> Or what about [M]ELPA Elisp, that natively byte-compiled > >> as well? > > > > What do you mean by "MELPA Elisp"? > > The Elisp you get from ELPA and MELPA and possibly other > places with the package manager. Same thing. The source of the Lisp code doesn't matter (of course). > >> If so, even more so, then why not all Elisp? > > > > Why not what? > > _If_ there is an advantage, and I agree it is, both in theory > and in practice, to natively byte-compile the GNU Emacs > (vanilla Emacs) Elisp, then how can it be that "the gains will > be null and void" to do the same with the local (HOME) Elisp? Most of the Lisp code you load does perform some processing that can be sped up. Of course, there are exceptions, but on the average compiling them produces tangible gains. Not so with init files.