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: Fri, 4 Feb 2022 11:57:21 +0000 Message-ID: References: <058b682b11240176288f@heytings.org> <83h79tjd2f.fsf@gnu.org> <058b682b11f58780b580@heytings.org> <83v8y8ij39.fsf@gnu.org> <6a5bb5a08b3d764611f9@heytings.org> <6a5bb5a08b6337d733c5@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="22776"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, mattiase@acm.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 Fri Feb 04 13:00:17 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 1nFxGC-0005lA-3K for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Feb 2022 13:00:16 +0100 Original-Received: from localhost ([::1]:49962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nFxGA-00025X-La for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Feb 2022 07:00:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nFxDT-0001Gy-0v for emacs-devel@gnu.org; Fri, 04 Feb 2022 06:57:27 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11906 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nFxDQ-00051J-K5 for emacs-devel@gnu.org; Fri, 04 Feb 2022 06:57:26 -0500 Original-Received: (qmail 41908 invoked by uid 3782); 4 Feb 2022 11:57:22 -0000 Original-Received: from acm.muc.de (p4fe1584b.dip0.t-ipconnect.de [79.225.88.75]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Feb 2022 12:57:22 +0100 Original-Received: (qmail 5334 invoked by uid 1000); 4 Feb 2022 11:57:21 -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, T_SCC_BODY_TEXT_LINE=-0.01 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:285860 Archived-At: Hello, Gregory. On Fri, Feb 04, 2022 at 00:11:46 +0000, Gregory Heytings wrote: > >>> 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. > >> Do you have an idea how this could be investigated? > > Usually such slowdown don't come from everywhere at the same time. So > > you need to "slice" our total time into subelements, and presumably some > > of those elements show a higher slowdown, so you can focus on those and > > start slicing them further. > > As you get closer to the source, the slowdown should become more marked. > You were too optimistic. > I just finished a detailed analysis of the slowdown of the execution of > Emacs' test suite, and it turns out that the slowdown is indeed spread > over all tests. > I attach the detailed results for each of the 389 tests. Each test has > been executed 2000 (two thousand) times, again on an unloaded up-to-date > Debian bookworm computer. Just for completion's sake, that was presumably without native compilation. > If you look closer at the results, you will see that the slowdown is > actually worse than 10%. The slowest of all tests (lisp/net/tramp-tests) > is only 2% slower, because it uses external processes and is therefore not > as much affected as other tests by the slowdown of bytecode execution > itself. If you remove that test from the calculations, you will see that > the slowdown is actually 17%, that is, the same slowdown as that of byte > compilation. > (FWIW, I was puzzled by the claim that byte compilation could be slowed > down markedly, and that at the same time general bytecode execution would > not. Byte compilation does not do anything that is fundamentally > different from general bytecode execution.) Compilation _does_ do things differently. It runs with symbols-with-pos-enabled bound to t, which makes EQ slower than when that variable is nil. To see this, have a look at the defition of lisp_h_EQ in src/lisp.h, around line 372. > My conclusion is that this merge should be backed out. Its performance > impact has not been properly resolved and assessed. These commits fixed a long standing bug, namely the outputting of wrong position information in compiler warning messages. Perhaps you could propose a better way of fixing that bug. For the record, I don't believe there is a better way which is practical. Also, there is something strange about the speed measurements on the test suite that gives such marked slowdowns. On measurements of "real" Emacs activities which don't involve compilation, the slowdowns measured were "no measurable difference", 1% and 3%. Perhaps you could hypothesize why there is such a large speed difference in those tests, but not in real Emacs use. Such an understanding could be useful. My guess is that there is an unusually large number of `eq's in the test suite, and that it does very little garbage collection or I/O. -- Alan Mackenzie (Nuremberg, Germany).