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: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp Date: Sun, 26 Feb 2023 08:25:32 +0200 Message-ID: <83k005j63n.fsf@gnu.org> References: <87bklw7ka3.fsf@dataswamp.org> <878rgyjgcc.fsf@dataswamp.org> <87o7pq21i4.fsf@dataswamp.org> <87ilfy20jf.fsf@dataswamp.org> <83pma6yahj.fsf@gnu.org> <87fsb21z1n.fsf@dataswamp.org> <83ilfyxiw6.fsf@gnu.org> <83k00btcsl.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10306"; 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 Sun Feb 26 07:26:03 2023 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 1pWATy-0002Pp-J3 for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 26 Feb 2023 07:26:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pWATU-0003Kf-TH; Sun, 26 Feb 2023 01:25:33 -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 1pWATQ-0003Iq-D2 for help-gnu-emacs@gnu.org; Sun, 26 Feb 2023 01:25:28 -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 1pWATQ-00045f-3p for help-gnu-emacs@gnu.org; Sun, 26 Feb 2023 01:25:28 -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=lfFx8V3REHPNzub7rFeybRUkIwmzmfJpw/bd5uUWSAU=; b=jSFUuBYjrLeR 0RM7axT+iYE1lzPL4CJkB0B5o/VaL7t//ZQKued1bp7m+DdK4el43dnxMCErqM81AVDTmqFMEsq3I Opaul2mRpGvSziiP1/fbIvg26ZG7N8udZQMfXqGiRenmX21UDhIX3RNIbDnuupimrmyrE6WN8hCCP DIFhUX3F5WY8j+KPT9o9k1VHp2K20a0jh+WIeqLLTgTi2hoHgeZS5w+TNp3V6xSQ/hcjBCZNJBThx roI3/1CJWIf4ppYSNr8A7ehf8AqcbL3mAdvW7r+Zp3BxrG8Sa8AudOvpw8Msq0BexOqmqk8GtHnPG TlgL4DPFra5ifBgGs1Nzjw==; 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 1pWATP-0007da-J6 for help-gnu-emacs@gnu.org; Sun, 26 Feb 2023 01:25:27 -0500 In-Reply-To: (message from Madhu on Sun, 26 Feb 2023 08:38:49 +0530) 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-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142841 Archived-At: > From: Madhu > Date: Sun, 26 Feb 2023 08:38:49 +0530 > > * Eli Zaretskii <83k00btcsl.fsf @gnu.org> : > Wrote on Tue, 21 Feb 2023 14:37:14 +0200: > >> From: Madhu > >> Date: Tue, 21 Feb 2023 12:34:21 +0530 > > >> Is my understanding of the documentation - that native compilation is > >> an automatic side effect of byte compiling, wrong? > > > > Yes, it's wrong. Native compilation happens automatically when you > > _load_ a .elc file, not when you compile it. > > The info manual I was looking at (info "(elisp) Native-Compilation > Functions") has this text > > "Native-Compilation is implemented as a side effect of > byte-compilation" It goes on by saying Thus, compiling Lisp code natively always produces its byte code as well So the above has nothing to do with _when_ does native compilation happen. It just says _how_ it works: by launching a byte-compilation and using its by-products internally to produce native code. > In any case maybe I should file a bug? because this the behaviour I > reported doesn't meet the expectations. In a fresh emacs -Q: the > following 3 forms all load a fib.elc file from the current directory > (say "/dev/shm") without producing an eln file. ("doesn't work") > > (byte-compile-file "fib.el" t) ; doesn't work > (load-file "fib.elc") ; doesn't work > (load "/dev/shm/fib.elc" nil nil t) ; doesn't work This is a feature, so filing a bug report against it won't be useful. Think about it: if the above would load a .eln file instead, how would a Lisp program be able to force Emacs to load a .elc file? Therefore, when you specify an explicit extension, be it .el or .elc, Emacs loads that specific file, nothing more, nothing less. Exactly like '(load "foo.el")' in previous versions of Emacs always loaded the .el file, even if the .elc file was available. > The only form which works seems to be when load is called with a full > pathname after omitting the ".el" or ".elc" suffix provided there is an > elc at that location. > i.e. > (load "/dev/shm/fib") > > only this form produces an eln file in the user's eln-cache directory. That's how it is supposed to work.