From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-26 eec71eb: Speed up replace-buffer-contents Date: Wed, 04 Jul 2018 05:31:21 +0300 Message-ID: <83va9vohom.fsf@gnu.org> References: <20180629135646.6054.66405@vcs0.savannah.gnu.org> <20180629135648.5C95A2053B@vcs0.savannah.gnu.org> <698fc242-71bf-0e6e-5e45-d1be45cbc074@cs.ucla.edu> <837emcjezc.fsf@gnu.org> <517756be-f05e-1fd1-afc9-f8b6d47252f2@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530671416 16012 195.159.176.226 (4 Jul 2018 02:30:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 02:30:16 +0000 (UTC) Cc: rgm@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 04 04:30:12 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 1faXYZ-00043a-RM for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2018 04:30:11 +0200 Original-Received: from localhost ([::1]:43644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faXaf-00065A-9e for ged-emacs-devel@m.gmane.org; Tue, 03 Jul 2018 22:32:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faXZo-000653-Td for emacs-devel@gnu.org; Tue, 03 Jul 2018 22:31:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faXZl-0004Cd-PO for emacs-devel@gnu.org; Tue, 03 Jul 2018 22:31:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faXZl-0004CO-L8; Tue, 03 Jul 2018 22:31:25 -0400 Original-Received: from [176.228.60.248] (port=4060 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1faXZk-0004jp-RN; Tue, 03 Jul 2018 22:31:25 -0400 In-reply-to: <517756be-f05e-1fd1-afc9-f8b6d47252f2@cs.ucla.edu> (message from Paul Eggert on Tue, 3 Jul 2018 13:14:29 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:226924 Archived-At: > Cc: rgm@gnu.org, emacs-devel@gnu.org > From: Paul Eggert > Date: Tue, 3 Jul 2018 13:14:29 -0700 > > Eli Zaretskii wrote: > > Profiling shows that 'diag' takes 32% of the CPU time, and > > buffer_chars_equal takes another 45%. So any significant gains will > > be in buffer_chars_equal, I think. > > Yes, that was what my intuition was pointing at as well. Among other things, we > can fix the quit problem without having a rbc_quitcounter variable. Fix how? Since the command can run for quite a few seconds, it is imperative that we give the user the possibility to quit. I originally had maybe_quit there, but profiling showed that it used a lot of CPU (because it accesses Lisp symbols, and was called for each character 'diag' wanted to compare), so I switched to rarely_quit. Last profile indicates rarely_quit takes about 6% of CPU time, which I think is a reasonably low price to pay for responsiveness. If you mean you have an idea for calling rarely_quit or its equivalent in a more elegant way (e.g., without a static counter), then it would be good, of course. But I'm not sure that will speed up the code, and we should be very careful not to slow it down just for QUIT's sake. > I typically measure effectiveness of performance tweaks when using the > 'configure' default of CFLAGS='-g3 -O2', since that's how it's typically built > downstream. If this particular problem is all about CFLAGS=-O0 please let me > know, as I guess I can look at that too (but would rather not). Which particular problem were did you allude to? I didn't (yet) profile the code in an optimized build, only in a -O0 build. It could be that the optimized build will show a different picture, although I doubt that. I might try an optimized build in a couple of days (but I never use -O3 in Emacs, only -O2).