From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Mon, 26 Nov 2018 08:14:28 -0800 Message-ID: <877egzizob.fsf@runbox.com> References: <20181117124534.GA8831@ACM> <83muq7u9rk.fsf@gnu.org> <20181123130904.GA2916@ACM> <87ftvphu2h.fsf@runbox.com> <20181126123913.GD4030@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1543248816 1060 195.159.176.226 (26 Nov 2018 16:13:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 16:13:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 17:13:31 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 1gRJVq-000068-L0 for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 17:13:30 +0100 Original-Received: from localhost ([::1]:37437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRJXx-0002V8-1v for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2018 11:15:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRJXN-0002Uf-AD for emacs-devel@gnu.org; Mon, 26 Nov 2018 11:15:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRJXK-0002ao-5g for emacs-devel@gnu.org; Mon, 26 Nov 2018 11:15:05 -0500 Original-Received: from aibo.runbox.com ([91.220.196.211]:56276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gRJXG-0002YS-Lo; Mon, 26 Nov 2018 11:15:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=7p0l/OpGj0c6NfKt2vAJXYD2l4D3QKbMCqrpty9NXbY=; b=jzd7yjp9BkA3GxwgmrKah7vf14 ek3JKa0VF+YhKOT2HMCTh8HfVoatmVHCNK5rMjkux32Spf053OmgcAxt8GywLrNRKx4b3EnKq/jq5 N4TPKo7EgdSOc9SlVPn2skLBVu+UHJAFq6VhjlbBSTntMeOE5kL1GaAslLCXO/26deUyC7wzcAJ3v suXP9irYPnFMA6+c4pGfnWmeWdLGDzeEBdoo72CIRlwPd1aQ3aYIp5QDoGtbpG2o/nYbMC08ite/e mB9Mg6u/I0EMPCcCKuQB27l2QiMJkEHJgumO+A8WvFBg2mWkGrmPyY/Dn6yJJbsN8e1MlvZ8zd12i OoP31dqQ==; Original-Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gRJX6-0007YR-Su; Mon, 26 Nov 2018 17:14:48 +0100 Original-Received: by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1gRJWp-0003JF-J5; Mon, 26 Nov 2018 17:14:32 +0100 In-Reply-To: <20181126123913.GD4030@ACM> (Alan Mackenzie's message of "Mon, 26 Nov 2018 12:39:13 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.220.196.211 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:231398 Archived-At: 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.) > 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. > My 8% (approximate) I measured by scrolling through xdisp.c, displaying > each window's worth on the way. Before repeating this timing, it's > necessary to insert a character at BOB then undo the insertion, so as to > erase the face and other properties throughout the buffer. > > Perhaps you might be able to adapt this exercise into your branch. At > any rate, I'd be interested if you could compare the timings on your > machine between old and new Emacs versions. Thanks for the suggestion and the code. The benchmark numbers in my last email were all created with --batch, meaning no display. But running benchmarks without --batch, so that redisplay can be benchmarked, is one of the things I'm working on.