From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps? Date: Wed, 26 Jan 2022 17:32:09 +0000 Message-ID: References: <83h79tjd2f.fsf@gnu.org> <058b682b11f58780b580@heytings.org> <83v8y8ij39.fsf@gnu.org> <6a5bb5a08b3d764611f9@heytings.org> <6a5bb5a08b5ba0712eae@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1658"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, larsi@gnus.org, Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 26 18:54:42 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 1nCmVG-0000ID-3E for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jan 2022 18:54:42 +0100 Original-Received: from localhost ([::1]:42378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCmVE-0004dR-Cv for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jan 2022 12:54:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCm9i-0003rk-E3 for emacs-devel@gnu.org; Wed, 26 Jan 2022 12:32:26 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:60679 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nCm9g-0004eI-LK for emacs-devel@gnu.org; Wed, 26 Jan 2022 12:32:26 -0500 Original-Received: (qmail 44324 invoked by uid 3782); 26 Jan 2022 17:32:10 -0000 Original-Received: from acm.muc.de (p4fe156d4.dip0.t-ipconnect.de [79.225.86.212]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 26 Jan 2022 18:32:09 +0100 Original-Received: (qmail 7682 invoked by uid 1000); 26 Jan 2022 17:32:09 -0000 Content-Disposition: inline In-Reply-To: <6a5bb5a08b5ba0712eae@heytings.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:285439 Archived-At: Hello, Gregory. On Tue, Jan 25, 2022 at 21:27:25 +0000, Gregory Heytings wrote: > > I've just tried timing $ make -j17 check on an up to date master, and a > > master two - four weeks old, both configured the same, with native > > compilation. Much of the run time was taken by native compilation. > > The two times were 42.966s and 48.547s. That's a difference of just > > under 13%. Not a systematic comparison, since make check may have got > > bigger in the last few weeks. > Which is consistent with the results I reported: about 40% of the time of > make check is used for byte-compilation, which is slowed down by ~17.5%, > and the rest is execution, which is slowed down by ~11%. What you reported was more educated guesses than results. Why don't you actually _measure_ some hopefully typical Emacs use, and tell us exactly how you got these measurements. Start off saying how you configured your build, followed by calling emacs -Q, with all the other detailed steps needed to duplicate your measurements. So far as I am aware, there have been just two comparative measurements done which don't involve compilation and aren't what you call "micro benchmarks". One was my timing scrolling through a C buffer. That gave a slowdown of ~1%. The other was Lars's timing, in his own words: "Yes. I've now done a few more realistic non-micro benchmarks -- (eww-open-file "/tmp/foo.html") -- and I see no measurable performance impact there at all." .. So the only benchmarks showing a > 1% slowdown are those involving compilation, and the "micro benchmarks". [ .... ] > > There is no "all" in the 10% slow down. That is a measure of the > > slowdown of $ make check, nothing else. > It's the time to execute ~110K lines of Elisp, exercising various parts of > Emacs. It's IMO a much more significant number than an ad-hoc > micro-benchmark. It's perhaps not the only one to take into account, but > it cannot be ignored either. But as pointed out above, it's not a measured time difference, it's an estimated one, complete with assumptions which you're probably not totally aware of. Would you please present us with some _measurements_. I think we're all agreed we accept the slowdown in compilation as a cost of actually doing the job right. So timings involving compilation aren't of all that much interest. > > But nobody else cared enough about the boostrap time to bother putting > > in the use of the byte-compiled compiler in early bootstrap until I did > > a week or so ago. > You may have seen that this optimization has no effect without > --with-native-compilation. This may explain that. The bootstrap time without native compilation is much shorter in any case. The point I'm making is that people are working themselves up into a frenzy about these small slowdowns, yet when they could have calmly done something about slow bootstrapping didn't really bother much. -- Alan Mackenzie (Nuremberg, Germany).