From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is Emacs buffer scroll/redisplay slow? Date: Sun, 19 Jan 2020 17:28:32 +0200 Message-ID: <834kwrzcrj.fsf@gnu.org> References: <20200119115146.GA9172@ACM> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="89014"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 19 16:29:01 2020 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 1itCVZ-000N4a-OR for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jan 2020 16:29:01 +0100 Original-Received: from localhost ([::1]:50976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itCVY-0006RY-Ql for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jan 2020 10:29:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45233) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itCV2-00061F-9c for emacs-devel@gnu.org; Sun, 19 Jan 2020 10:28:29 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1itCV1-0000qS-RZ; Sun, 19 Jan 2020 10:28:27 -0500 Original-Received: from [176.228.60.248] (port=4786 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1itCV0-0001kO-G5; Sun, 19 Jan 2020 10:28:27 -0500 In-reply-to: (message from Fabrice Popineau on Sun, 19 Jan 2020 15:24:19 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:244372 Archived-At: > From: Fabrice Popineau > Date: Sun, 19 Jan 2020 15:24:19 +0100 > Cc: Emacs developers > > > .... scrolling through an elisp buffer: I started the timer by hand and > > scrolled down for 1000 lines .... > > How, exactly, did you do the scrolling? How did you stop the scrolling > at 1000 lines? Do you get this slowness on any elisp buffer, or is it a > particular one? > > I used my phone timer. It was my init.el file but I get the same result with dired.el You didn't answer the question about the exact way of scrolling you used. Also, did you measure the CPU time it took, out of those 35 sec? (I assume the time you measured was elapsed time, yes?) > > .... and it took 45s on Windows/WSL and 35s on Windows/native. > > That is slow indeed. > > Definitely. Not necessarily. The elapsed time has little to do with the speed we scroll. > Have you tried profiling this scrolling, yet? If not, I suggest you do, > with M-x profiler-start , running the scrolling, then M-x > profiler-report. In the report buffer, hit to get successively > deeper results. > > This may well give you an idea where the slowness is happening. > > > You are right. I should have tried it right away. > > image.png > > I am not sure there is anything unexpected in there. > The lisp machinery interpreting commands accounts for most of the time, > especially `completing-read-default' and I wonder why? Is it because of the `make-composed-keymap' call > which occurs in `completing-read-default'? Which brings us back to the question of how did you scroll through those 1000 lines. I wouldn't expect to see completion code so high on the profile, it almost sounds like the profile didn't measure the important stuff. (Was this the CPU profile or "memory" profile, btw? The latter is largely useless.)