From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Mon, 26 Nov 2018 17:06:52 +0000 Message-ID: <20181126170652.GF4030@ACM> References: <20181117124534.GA8831@ACM> <83muq7u9rk.fsf@gnu.org> <20181123130904.GA2916@ACM> <87ftvphu2h.fsf@runbox.com> <20181126123913.GD4030@ACM> <877egzizob.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543252124 27425 195.159.176.226 (26 Nov 2018 17:08:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 17:08:44 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Gemini Lasswell Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 18:08:39 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gRKND-00072B-9C for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 18:08:39 +0100 Original-Received: from localhost ([::1]:37859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRKPJ-0003Cg-Qj for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 12:10:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRKOx-0002vk-BX for emacs-devel@gnu.org; Mon, 26 Nov 2018 12:10:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRKOn-0005YJ-PX for emacs-devel@gnu.org; Mon, 26 Nov 2018 12:10:27 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:55696 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gRKOn-0005WR-FG for emacs-devel@gnu.org; Mon, 26 Nov 2018 12:10:17 -0500 Original-Received: (qmail 17391 invoked by uid 3782); 26 Nov 2018 17:10:15 -0000 Original-Received: from acm.muc.de (p2E5D5CCE.dip0.t-ipconnect.de [46.93.92.206]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 26 Nov 2018 18:10:13 +0100 Original-Received: (qmail 29522 invoked by uid 1000); 26 Nov 2018 17:06:52 -0000 Content-Disposition: inline In-Reply-To: <877egzizob.fsf@runbox.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231399 Archived-At: Hello again, Gemini. On Mon, Nov 26, 2018 at 08:14:28 -0800, Gemini Lasswell wrote: > Alan Mackenzie writes: > Hi Alan, > > syntax-tasks-{backward,forward}-word presumably time backward-word and > > forward-word. bytecomp-tasks-compile-doc I'm not sure about, is that > > the extraction of doc strings from .elc files? > You are correct about syntax-tasks-*. bytecomp-tasks-compile-doc > measures the time it takes to compile the function 'doctor-doc' from > doctor.el (since I want benchmark tasks to run in old versions of Emacs, > I went looking in lisp/play for something that hadn't changed in a long > time.) Ah, "doc" as in "doctor", not "document". :-) When I compile doctor.el with (time-it (byte-compile-file ".../play/doctor.el")), I see a slow down of 9.9%, which is surprisingly little, given how much extra processing is involved when symbols-with-positions-enabled is bound to non-nil. Compiling a single function from that file, you see a 24% slowdown (if I remember the figures correctly). There's some explaining to do there to account for the difference between what we see. My machine is a desktop with an AMD Ryzen processor, and I run Gentoo GNU/Linux. Maybe the processor architecture accounts for some of the difference. > > After getting over my knee-jerk reaction, my thoughts are that these > > timings are not of things which, of themselves, would directly concern a > > user. A fill-paragraph will take 15% more time, but would a user > > actually notice this, given that the operation is usually instantaneous? > > Good things to benchmark would be interactive commands which feel a bit > > sluggish anyway. CC Mode redisplay is a good candidate for this (see > > below). ;-) > > From your timings, my gut feeling is that the 15% slowdown in > > fill-tasks-fill-paragraph probably represents fairly closely the > > slowdown in Emacs as a whole. It is testing a "macro" operation rather > > than an isolated primitive. > Every time I use a keyboard macro to edit every line in a file, I wonder > why it takes so long. kmacro-tasks-edit-lines changes 10 lines of > "1. Flintstone, Fred" to read "Fred Flintstone" using basic editing > commands. From the current short list of benchmarks, it would be my > choice for representing Emacs as a whole. That one was 18%. I think it would be a fair summary to say that you are seeing a 15 - 20% slowdown in "real life" measurements (which excludes the byte compilation, which everybody agrees can take as long as it likes). I seem to be seeing a lesser slowdown, of around 10%, although I haven't yet got around to running your new branch and doing a solid test. Quite likely, Eli is keeping a keen eye on this part of the thread to see how things develop. ;-) My feeling is that the new branch is up to being integrated into master eventually, with "only" 10 - 20% slowdown, but then I'm not exactly impartial. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).