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: Sat, 22 Jan 2022 22:55:44 +0000 Message-ID: References: <87zgnvyb5y.fsf@gnus.org> <87bl03j10s.fsf@gnus.org> <9D116A4B-622F-4C80-83E6-2CDD7ED9AD25@acm.org> <58bb8030d532070ed420@heytings.org> <838rv7mzn4.fsf@gnu.org> <58bb8030d5ec3a6bde9f@heytings.org> <837darmygd.fsf@gnu.org> <58bb8030d59733b52b8d@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38581"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, Eli Zaretskii , larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 22 23:56:45 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 1nBPJM-0009ww-R1 for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Jan 2022 23:56:44 +0100 Original-Received: from localhost ([::1]:58534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBPJL-0000MZ-DM for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Jan 2022 17:56:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBPIX-00083K-9n for emacs-devel@gnu.org; Sat, 22 Jan 2022 17:55:53 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:25859 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nBPIU-0001QS-AE for emacs-devel@gnu.org; Sat, 22 Jan 2022 17:55:52 -0500 Original-Received: (qmail 55712 invoked by uid 3782); 22 Jan 2022 22:55:47 -0000 Original-Received: from acm.muc.de (p2e5d54f8.dip0.t-ipconnect.de [46.93.84.248]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 22 Jan 2022 23:55:47 +0100 Original-Received: (qmail 7749 invoked by uid 1000); 22 Jan 2022 22:55:44 -0000 Content-Disposition: inline In-Reply-To: <58bb8030d59733b52b8d@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:285235 Archived-At: Hello, Gregory. On Sat, Jan 22, 2022 at 22:36:11 +0000, Gregory Heytings wrote: > >>> That's consistent with what was reported at the beginning of this > >>> thread (~7% slowdown). Byte compilation is expected to be slightly > >>> slower with this change. > >> But make check does a lot more than byte compilation, or am I missing > >> something? > > Not much more, IME. > That's not what the numbers tell us (again 3b33a14380 vs 7922131bb2): > make -j1 check: 181s (69s byte-compilation, 112s execution) vs 162s (58s byte-compilation, 104s execution) > make -j4 check: 45s (17s byte-compilation, 28s execution) vs 40s (15s byte-compilation, 25s execution) > make -j8 check: 26s (9s byte-compilation, 17s execution) vs 23s (7s byte-compilation, 16s execution) > In short, the compilation time in make check is slower (which is > expected), but the execution time in make check is also consistently ~7% > slower. Yes. But bug #22288 and friends are fixed. I did some comparisons using elisp-benchmark earlier on today. With the bug fix, the timings were just 2½% slower. Anything doing compilation (whether byte- or native-), or doing lots of tight loops will be slower than that -2½%. Other programs (such as CC Mode) which spend a lot of time in the regexp engine, or garbage collection, or I/O, will have lost less than that 2½%. But the main thing is that longstanding bugs have been fixed. -- Alan Mackenzie (Nuremberg, Germany).