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, 5 Feb 2022 11:42:33 +0000 Message-ID: References: <83h79tjd2f.fsf@gnu.org> <058b682b11f58780b580@heytings.org> <83v8y8ij39.fsf@gnu.org> <6a5bb5a08b3d764611f9@heytings.org> <6a5bb5a08b6337d733c5@heytings.org> <87ilttg81b.fsf@gnus.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="27922"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, Gregory Heytings , Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 05 12:43:33 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 1nGJTY-00078v-Bs for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Feb 2022 12:43:32 +0100 Original-Received: from localhost ([::1]:46502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGJTX-0004QL-5t for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Feb 2022 06:43:31 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55310) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGJSk-0003jl-7D for emacs-devel@gnu.org; Sat, 05 Feb 2022 06:42:42 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:48301 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nGJSh-00057X-3O for emacs-devel@gnu.org; Sat, 05 Feb 2022 06:42:41 -0500 Original-Received: (qmail 556 invoked by uid 3782); 5 Feb 2022 11:42:37 -0000 Original-Received: from acm.muc.de (p2e5d5062.dip0.t-ipconnect.de [46.93.80.98]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Feb 2022 12:42:36 +0100 Original-Received: (qmail 9032 invoked by uid 1000); 5 Feb 2022 11:42:33 -0000 Content-Disposition: inline In-Reply-To: <87ilttg81b.fsf@gnus.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, T_SCC_BODY_TEXT_LINE=-0.01 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:285898 Archived-At: Hello, Lars. On Sat, Feb 05, 2022 at 07:08:16 +0100, Lars Ingebrigtsen wrote: > Gregory Heytings writes: > > 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. > [...] > > 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. > Thanks, that's interesting, but it doesn't really answer the question of > why it's so hard to see these performance regressions in actual use. I > tried to benchmark Alan's patches before they went in by doing things > like measuring shr DOM rendering, and saw essentially no measurable > difference. And 17% vs "essentially nothing" is a big gap. > So it's still not clear what's being measured. Is ert doing something > that's triggering these slowdowns? Is it only measurable in "emacs > -batch"? Is there something else that makes the test suites so much > slower while we're not seeing that in real usage? I just tried to disassemble an ert-form for (ert-deftest parse-partial-sexp-paren-comments () ...), in tests/src/syntax-tests.el. I haven't yet managed it, but just dumping (get 'parse-partial-sexp-paren-comments 'ert--test) onto the *Messages* buffer, it is apparent that symbols with position have somehow got into the compiled form. They appear like this: \312\313^B\301\"D\262^A\244\240\210\314\303\242!\207" [V0 V1 V2 V3 (should (# (# \ .. This might have something to do with the slowdown, it might not. But there is definitely a bug somewhere to fix. I don't know yet whether these dumped forms actually get executed, or whether they're just there to be displayed on an error. If they do get executed, the SWP there might explain the slowdown in the tests. > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany).