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 11:27:27 +0000 Message-ID: References: <837darmygd.fsf@gnu.org> <58bb8030d59733b52b8d@heytings.org> <83r18zkmd5.fsf@gnu.org> <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=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, Eli Zaretskii , larsi@gnus.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 25 12:29:49 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 1nCK1E-00074j-RD for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 12:29:48 +0100 Original-Received: from localhost ([::1]:57972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCK1D-0002tO-Lz for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 06:29:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCJzF-0000c0-Bc for emacs-devel@gnu.org; Tue, 25 Jan 2022 06:27:48 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11639 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nCJzD-0001nG-0P for emacs-devel@gnu.org; Tue, 25 Jan 2022 06:27:44 -0500 Original-Received: (qmail 7211 invoked by uid 3782); 25 Jan 2022 11:27:28 -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 12:27:28 +0100 Original-Received: (qmail 6527 invoked by uid 1000); 25 Jan 2022 11:27:27 -0000 Content-Disposition: inline In-Reply-To: <6a5bb5a08b3d764611f9@heytings.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=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:285352 Archived-At: Hello, Gregory. On Tue, Jan 25, 2022 at 08:59:00 +0000, Gregory Heytings wrote: > >> At least the test suite is not a micro-benchmark. I exercises a large > >> subset of Emacs features, and I don't see anything in these ~110K lines > >> of Elisp that make them significantly different from other Elisp > >> programs. My conclusion is that Emacs is now, on average, about 10% > >> slower. > > Your conclusion is premature. While micro-benchmarks don't represent a > > typical Emacs usage, neither are the tests in the test suite. They are > > run in batch mode, and the don't involve important Emacs subsystems, > > such as the display engine. > > So the actual slowdown in "normal" usage could be quite different from > > what the test suite measures. > I think you understood what I meant: bytecode execution in Emacs is now, > on average, about 10% slower. The C level EQ operation takes twice as long when the operands do not match, and the same time as before when they do match. When one of the operands is a literal nil, there is no increase in execution time. The above doesn't apply to compilation, whether byte or native, where the slowdown in the EQ operation is more marked. > Are there other benchmarks (not micro-benchmarks) that could be used > to reach what you would consider a mature conclusion? There is Andrea Corallo's elisp-benchmark package. You could try the following, in conjunction with benchmark-run. It scrolls through an entire buffer: (defun time-scroll-b (&optional arg) (condition-case nil (while t (if arg (scroll-down) (scroll-up)) (sit-for 0)) (error nil))) -- Alan Mackenzie (Nuremberg, Germany).