From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Mon, 03 Oct 2022 14:33:09 -0400 Message-ID: References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> <87fsg6m5zx.fsf@trouble.defaultvalue.org> <83mtaeys7k.fsf@gnu.org> <87o7uukngi.fsf@trouble.defaultvalue.org> <83a66czz5q.fsf@gnu.org> <83mtacyfvl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29498"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: rlb@defaultvalue.org, tomas@tuxteam.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 03 20:57:46 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 1ofQdO-0007YR-78 for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 20:57:46 +0200 Original-Received: from localhost ([::1]:57756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofQdN-0005RM-4r for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 14:57:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofQFt-0007VQ-Fo for emacs-devel@gnu.org; Mon, 03 Oct 2022 14:33:45 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31518) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofQFf-0003Rd-PG; Mon, 03 Oct 2022 14:33:28 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 444F680796; Mon, 3 Oct 2022 14:33:13 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3AC128025C; Mon, 3 Oct 2022 14:33:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1664821991; bh=qWUUZhj4UkeCmJykl/yA4NQF3M/Jj/MzXzEQcMa0AOw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mkyfrvsg9psZjrWGmSZ3ObkRQxsDPnWuY2YL9543wthawtVtI0T+2kwXiQby2HNwp jz86cxNMs5IWNzA6h0ghRbYV/EgBbCR0fOoBlq0tB99p5DV1K3xQdhUyQ8TOKCGLzA by/Gp60gSvbJu16bEiu+Ck3N6LFSA4nEsDc8v3oqsY9lYarSSmTF0Qjg9bSc+1/p4I KMv55T7rrBPL5V9qE2iO6i3QWq9wDU2zflww1w6ZmK0xh853+6gqo3V+9LUBJ9Frxv QMwANydN254SojLLsQKFgh9hnsOOXgGaXNhyDRTvoyVxOaVubtkV2BxWJ9IGnIo5zR idw62JELlu51w== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 14159120DCE; Mon, 3 Oct 2022 14:33:11 -0400 (EDT) In-Reply-To: <83mtacyfvl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 03 Oct 2022 20:30:06 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:296789 Archived-At: >> FWIW, during the stealth jit-lock discussion, several people mentioned the >> battery impact. > Yes. And jit-stealth is different, in that it takes a much longer > time for it to become quiet, because it works in small chinks, and > only when Emacs is actually idle. JIT native-compilation is much > faster, and also uses several execution units of the CPU in parallel. Indeed, it's quite different. I think even more important than the above is the fact that it's a one-time thing only (for typical use cases at least), whereas the jit-lock-stealth cost was paid over and over again after every buffer modification. >> And the issue is not subprocesses per se, but it's extra processing that >> happens outside of the control of the user. > How do you mean "outside of the control of the user"? The user causes > it by loading a feature. When a user loads a feature, this request doesn't say explicitly "and native compile the file". And there is no direct way to "just load this package without compiling it". So the compilation is not really under the control of the user. I don't think users know, when they load a feature, if it's the first time they loaded this feature in this version of Emacs, so by and large they can't predict when the compilation does happen. To be clear: I don't think it's a problem. I just think it's part of the reason for the reaction. > How is that different from any other command that uses a subprocess > under the hood? It's different in that for those other commands, the users cannot get the result they want without running that subprocess, so even if they're not fully aware of it, they do have some vague idea it's inevitably going to happen. In contrast, the compilation is not indispensable, (so much so that the past it never happened). >> Probably not, no. It's likely mostly a question of perception, so if we >> could make it completely invisible the "problem" would disappear :-) >> But the fact that lazy native compilation tends to pop up warnings (and >> to make matters worse, it does so ... without warning) makes it very >> much visible instead. > > On my system, I don't see any warnings. That's presumably because you stick to the bundled packages (where we've managed to keep a "no compilation warnings" state for the last few years) or the few third party packages which are careful enough to eliminate all warnings. The rise of ELPA has removed most of the cases where native compilation will miscompile files (because ELPA forces the .el files to be compiled in a "standard" way rather than using ad-hoc Makefile rules which the native compiler cannot and does not try to reproduce), but compilation warnings are still very common (the situation is improving, tho, and arguably the warnings popping up out of the blue during lazy native compilation may prove to be a good way to convince more package authors to clean up their act). Stefan