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: Correct byte compiler error/warning positions. The solution! Date: Mon, 29 Nov 2021 11:50:19 +0000 Message-ID: References: <83pmqm16vz.fsf@gnu.org> <8335nh29pt.fsf@gnu.org> <83wnktzxb2.fsf@gnu.org> <83ilwcyc6o.fsf@gnu.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="19861"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 29 12:51:55 2021 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 1mrfCN-00050L-Cs for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 12:51:55 +0100 Original-Received: from localhost ([::1]:40812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrfCM-0007Hn-Bd for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 06:51:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40062) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrfB8-0006Oy-9T for emacs-devel@gnu.org; Mon, 29 Nov 2021 06:50:38 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:12901 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mrfB5-0006lV-Iq for emacs-devel@gnu.org; Mon, 29 Nov 2021 06:50:38 -0500 Original-Received: (qmail 84475 invoked by uid 3782); 29 Nov 2021 11:50:20 -0000 Original-Received: from acm.muc.de (p4fe15bd7.dip0.t-ipconnect.de [79.225.91.215]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 29 Nov 2021 12:50:19 +0100 Original-Received: (qmail 5525 invoked by uid 1000); 29 Nov 2021 11:50:19 -0000 Content-Disposition: inline In-Reply-To: <83ilwcyc6o.fsf@gnu.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:280460 Archived-At: Hello, Eli. On Sun, Nov 28, 2021 at 09:25:03 +0200, Eli Zaretskii wrote: > > Date: Sat, 27 Nov 2021 23:05:12 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > The timings I have for scrolling in the forward direction (each time > > preceded by M-x garbage-collect, and typing/erasing a character to clear > > the font-lock settings) are: > > (master branch, no native compilation): > > 20.847s, 21.609s, 19.459s, 21.570s, 21.651 > > (New code with correct warning messages, no native compilation): > > 21.284s, 42.152s ????, 19.927s, 19.960s, 22.259s, 22.198, 22.209s. > > The input to configure was the same in both cases, namely > > ./configure --with-gif=no --with-tiff=no --with-gpm. > > , and the timings were done on the Linux console. > > No, I don't understand that 42s run. A lot of garbage collection, > > perhaps? > You should always record the time take by GC and subtract it from the > elapsed time. I believe benchmark-run shows that time, so please use > it in the comparison. OK, I've done that a few times, thanks. There were 97 GCs in a run, totalling around 5 seconds. I'll try it more systematically some time. I've become a little confused over the "==" in lisp_h_NILP that we were discussing. Omitting the XLI calls causes GCC 10.3.0 to build a smaller executable. (This was with debugging info switched off.) I realise this is not acceptable, since there are other systems this wouldn't compile under. Anyhow, I've committed the current state in the new branch scratch/correct-warning-pos. It should build and run OK, although I haven't tried it out with native compilation, yet. It is marginally slower than master. Maybe we can merge it into master some time for Emacs 29. -- Alan Mackenzie (Nuremberg, Germany).