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: Mon, 03 Oct 2022 19:19:06 +0300 Message-ID: <835yh0zxqd.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> <83sfk6ahty.fsf@gnu.org> <87v8p1aiof.fsf@melete.silentflame.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28336"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rlb@defaultvalue.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 03 18:22:26 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 1ofOD3-00077D-QY for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 18:22:26 +0200 Original-Received: from localhost ([::1]:49736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofOD2-0006Op-CT for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 12:22:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofOA6-0003bB-L5 for emacs-devel@gnu.org; Mon, 03 Oct 2022 12:19:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44752) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofOA2-00081w-Fi; Mon, 03 Oct 2022 12:19:18 -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=tlJnULeVkrSVjt7WIgerlzCwpXRttwJ/zirgiA/lDv4=; b=GfUUsuXodOoh SouOGTBuNFOp1DNuQ0UmkIhkx3GGmyUWDMtCN1zQV5woSWr6ZfKvn9ESWxFyBUXTXpNoAVf589gtJ Kmu1AQ5dQwn1wMFgemrkypN4RfUdFqVOaZuu/BumgsOO6nqXTNkPOZwWb5G2vW/SxrjTKwcRzpEBw 1aHrgUCHYlrfZarKAQ1C2Vg/g8tJc8nGVuQFKKM3WOFeRvm7zHOh8S3cpuYhcemuavWxDciB+wfat cqI1UXA4bnfO4eVZAo+0Z/hwg2Hp9Vtj0BN9Hp3iYaya/ALfJKCHX9XS4pZyd7bhL9mEarHrefUmd 50HyVapDN5m1o68zqvzvwA==; Original-Received: from [87.69.77.57] (port=4613 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 1ofO9y-0003mY-UT; Mon, 03 Oct 2022 12:19:18 -0400 In-Reply-To: <87v8p1aiof.fsf@melete.silentflame.com> (message from Sean Whitton on Sun, 02 Oct 2022 16:51:12 -0700) 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:296762 Archived-At: > From: Sean Whitton > Cc: Rob Browning , monnier@iro.umontreal.ca, > david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org > Date: Sun, 02 Oct 2022 16:51:12 -0700 > > The point with battery consumption is not about running vs. standby. > The issue is that while users expect that running apt-get will drain the > battery, they expect that once apt-get is done, the only battery-hungry > processes are ones they start themselves. How does this work in practice? I mean, what exactly do you mean by "processes they start themselves"? You mean, you know by heart each Emacs command that invokes a subprocess, and avoid to invoke them all unless the laptop is plugged in? I don't believe this is practical, because even "C-x C-f" invokes a a subprocess when you visit a file under VCS (which I guess happens a lot to the likes of you and me). And how can a person avoid all of those commands? What am I missing? > Laptop users typically avoid running apt-get without mains power > plugged in. If I do an 'apt-get upgrade' then afterwards my CPU > will be churning away compiling addon packages, so I can't just > unplug. Did you actually try to see that "churning away" in practice, did you look at the time this typically takes, the resources (battery and otherwise) it consumes, etc.? If so, can you share the data: how many *.eln files were produced in how many minutes, how much battery did that consume? You see, I have my data, and it seems to indicate a very short period of initial compilations for a modest consumption of resources. (This isn't a laptop, but I'm acutely aware of my system's load at all times, and have it on the mode line, so I know what kind of computation is going on during that time.) The data I see here doesn't look like it should be a problem for anyone, as long as files are compiled only as they are used. In my case, for example, I see maybe half a dozen *.eln files compiled after the initial startup. I expect to see that on any machine where a user has steady usage patterns -- the compilation flats out very quickly. I cannot imagine how will your CPU churn out for any significant time after an upgrade. A typical compilation of a single .el file is usually very fast, exceptions are extremely rare. And I barely notice the effect of that on system responsiveness. So I could imagine that many people perhaps base these judgments on something they didn't actually try, but just imagined to themselves, and imagined incorrectly, or based their opinions on some other compilations of different languages in different environments. I urge people to actually try this and see what it does, before making up your minds.