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: Sun, 16 Jan 2022 14:45:28 +0000 Message-ID: References: <83mtjwzwkb.fsf@gnu.org> <87r198ytog.fsf@gnus.org> <87lezfzy5h.fsf@gnus.org> <83sftnyilw.fsf@gnu.org> <83mtjvyd4t.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="16545"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 16 15:46:57 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 1n96o4-000476-TF for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jan 2022 15:46:56 +0100 Original-Received: from localhost ([::1]:38874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n96o3-0000cm-BE for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jan 2022 09:46:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36464) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n96mp-0007gE-LH for emacs-devel@gnu.org; Sun, 16 Jan 2022 09:45:40 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:58445 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1n96ml-0001fv-HZ for emacs-devel@gnu.org; Sun, 16 Jan 2022 09:45:38 -0500 Original-Received: (qmail 52694 invoked by uid 3782); 16 Jan 2022 14:45:31 -0000 Original-Received: from acm.muc.de (p2e5d50dc.dip0.t-ipconnect.de [46.93.80.220]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 16 Jan 2022 15:45:31 +0100 Original-Received: (qmail 32367 invoked by uid 1000); 16 Jan 2022 14:45:28 -0000 Content-Disposition: inline In-Reply-To: <83mtjvyd4t.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:284822 Archived-At: Hello, Eli. On Sun, Jan 16, 2022 at 16:21:54 +0200, Eli Zaretskii wrote: > > Date: Sun, 16 Jan 2022 14:06:59 +0000 > > Cc: Lars Ingebrigtsen , emacs-devel@gnu.org > > From: Alan Mackenzie > > > Since this is glaringly inconsistent with the timings Alan published, > > > I think it would be a good idea to measure the difference for each of > > > the*.el files, because it could be that a couple of outliers skew the > > > entire picture. That is, put the 'time' command inside the 'do', and > > > don't use -j8; then compare the outputs. > > On the branch, the byte compiler is doing more work than on master. My > > timings from yesterday were about the speed of Emacs in daily use rather > > than while compiling. > Are you saying that the measured slowdown is specific to the > byte-compiler, and will not affect other uses of Lisp, or affect them > much less heavily? Yes. The byte compile, as expected, is more slowed down than other software. On a quick measurement of compiling comp.el, I found a slowdown of around 12% > Because the byte-compiler is just another Lisp program, it doesn't in > general do anything an arbitrary Lisp program won't do. It does. It runs with symbols with position activated, so any operation involving an EQ which doesn't match is going to be significantly slower. > Can you point to the places in the byte-compiler that do significantly > more work on the branch? Every EQ operation. With symbols-with-pos-enabled set, the EQ has appreciably more work to do. If the first binary comparison does not match, it needs to check the possibilities of symbols with positions. With symbols-with-pos-enabled set to nil, an EQ has only a little more work to do (namely, checking symbols-with-pos-enabled and finding it unset). > Can you show a profile where this could be seen quantitatively? I'm not sure I understand. The slowdown in the byte compiler is distributed throughout the Emacs C Code. It doesn't happen at any particular isolated place. -- Alan Mackenzie (Nuremberg, Germany).