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: Tue, 25 Jan 2022 20:58:04 +0000 Message-ID: References: <835yq9ls7j.fsf@gnu.org> <058b682b11240176288f@heytings.org> <83h79tjd2f.fsf@gnu.org> <058b682b11f58780b580@heytings.org> <83v8y8ij39.fsf@gnu.org> <6a5bb5a08b3d764611f9@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="4329"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, mattiase@acm.org, Gregory Heytings , Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 25 21:59:44 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 1nCSum-0000xC-CX for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 21:59:44 +0100 Original-Received: from localhost ([::1]:41354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCSul-0003BT-Ch for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 15:59:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60292) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCStE-0001mr-P2 for emacs-devel@gnu.org; Tue, 25 Jan 2022 15:58:08 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:27529 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nCStC-0007qj-Ku for emacs-devel@gnu.org; Tue, 25 Jan 2022 15:58:08 -0500 Original-Received: (qmail 91499 invoked by uid 3782); 25 Jan 2022 20:58:04 -0000 Original-Received: from acm.muc.de (p4fe1523e.dip0.t-ipconnect.de [79.225.82.62]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 25 Jan 2022 21:58:04 +0100 Original-Received: (qmail 7387 invoked by uid 1000); 25 Jan 2022 20:58:04 -0000 Content-Disposition: inline In-Reply-To: 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=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:285392 Archived-At: Hello, Stefan. On Tue, Jan 25, 2022 at 14:26:31 -0500, Stefan Monnier wrote: [ .... ] > >> I do find the slowdowns discussed here rather worrisome. > >> I thought the original agreement was that it was OK to install this > >> change if the slowdown could be brought down to about 1% or below (for > >> the non-compilation case). > >> More importantly, I wonder how slowing down EQ by a factor of 2 can end > >> up costing 10% of runtime when running the test suite. I think this > >> deserves investigation. > > Maybe it's because a lot of the time spent by make check is spent in > > compilation, whether byte or native. Compilation _is_ slower, by quite > > a bit. > No, we are talking about the execution time: 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. > Gregory Heytings wrote: > In short: byte-compilation is ~17.5% slower, execution is ~11% > slower. Nowhere near the "in the region of 1%" that was announced. I don't think Gregory has ever been specific about what precisely he has timed, and how. I have. And the 1% figure was for a specific timing, namely scrolling through xdisp.c from start to end, fontifying as we go. > > When I ran elisp-benchmark on the before and after versions, the change > > was 2½% (on a native compiled Emacs). > So, something changes the cost from 2-3% to 11%. Maybe it's native > compilation (tho I don't know if Gregory ran these with native > compilation or not), or maybe it's somewhere in the nature of the code > in the test suite, or ... .... or all of these things. I suspect it's mainly the increased cost of the compilation. > Mind you, I consider 2½% to be already quite different from "about > 1%", ... Really? You have a batch job which you were expecting to take a minute. Now, instead, it takes 61 seconds. What would you have done with that extra second, which is now no longer in your life? > but I think we should first focus on those 11% reports because I don't > think I'm willing to slow down all execution by 10% just to get better > position info in the compilation warnings. We're not talking about "better" position info. We're talking about correct versus incorrect; functional versus buggy. Compilation has got slower because it's no longer skimping on an essential portion of its task. You are taking up the emotional element of Gregory's posts. There is no "all" in the 10% slow down. That is a measure of the slowdown of $ make check, nothing else. The time to bootstrap is about 7% - 8% slower after the bug fix. 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. Bootstrap has become steadily slower over the months as features have been added. Does anybody really care? If you scroll through C Mode code fontifying it, the fixed Emacs is about 1% slower. If you run the elisp-benchmarks, it's about 2½% slower. If we were talking about the output of a chemical factory, a 2½% reduction in output would probably be serious. But we're not, we're talking about a use case where the computer's waiting for the next key stroke nearly all the time anyway. But do some comparative timings. I think you'll find the typical loss in performance is a good deal less than 11%. > Stefan -- Alan Mackenzie (Nuremberg, Germany).