From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45898: 27.1; wedged in redisplay again Date: Fri, 01 Jul 2022 15:39:19 +0300 Message-ID: <83letddn2g.fsf@gnu.org> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <83v8t6us8t.fsf@gnu.org> <87zgiinptk.fsf@gnus.org> <83mteiufih.fsf@gnu.org> <877d5kojbo.fsf@gnus.org> <83zgigu3e0.fsf@gnu.org> <500e4b9c69f2a90e7cf05b956178d71b@webmail.orcon.net.nz> <835yl3tnv3.fsf@gnu.org> <83iloyo0x7.fsf@gnu.org> <83mte5jukr.fsf@gnu.org> <837d57gbed.fsf@gnu.org> <83o7yicx3p.fsf@gnu.org> <83pmir5lwc.fsf@gnu.org> <83mtdu68cl.fsf@gnu.org> <837d4yf18n.fsf@gnu.org> <6A3A8E3E-9FF6-4509-893B-EBFF7B573CDA@gmail.com> <83y1xde5cs.fsf@gnu.org> <25F8DA8E-0C2B-4996-9DB0-E89BDE81C924@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34936"; mail-complaints-to="usenet@ciao.gmane.io" Cc: psainty@orcon.net.nz, larsi@gnus.org, Emacs-hacker2018@jovi.net, monnier@iro.umontreal.ca, 45898@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 01 14:40:41 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1o7Fwv-0008te-Ef for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Jul 2022 14:40:41 +0200 Original-Received: from localhost ([::1]:46518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7Fwu-0000ZO-4P for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Jul 2022 08:40:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7FwJ-0000Y6-0R for bug-gnu-emacs@gnu.org; Fri, 01 Jul 2022 08:40:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42703) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o7FwI-0001PJ-Nb for bug-gnu-emacs@gnu.org; Fri, 01 Jul 2022 08:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o7FwI-0004uw-L5 for bug-gnu-emacs@gnu.org; Fri, 01 Jul 2022 08:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Jul 2022 12:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45898 X-GNU-PR-Package: emacs Original-Received: via spool by 45898-submit@debbugs.gnu.org id=B45898.165667916618848 (code B ref 45898); Fri, 01 Jul 2022 12:40:02 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 1 Jul 2022 12:39:26 +0000 Original-Received: from localhost ([127.0.0.1]:36600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7Fve-0004tq-CR for submit@debbugs.gnu.org; Fri, 01 Jul 2022 08:39:26 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7FvZ-0004ta-R2 for 45898@debbugs.gnu.org; Fri, 01 Jul 2022 08:39:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7FvS-0001IY-2T; Fri, 01 Jul 2022 08:39:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=wVhAMxvVgoo0CqFSEEo95JK0P4AO8koiLpeWmvIyDEg=; b=dUli0gA9NFESU4lqTVCk b031AKG1bvhAaeWyuS3A0ui5jDGjCOSMXO+6bjzE6vUT+qdTSs2EAqorecqIYxXSft0uZ0+tcRKGS lNahAkQGWotbakRzelp1GLxOPGUBYilgnw4EOHyL0YcalaBcHL664gckPTPLEgGJuhdCyUIlfAXC2 UnXmwpuVYVOPg5otAaHp/k6e9MJEJKj852mE0v+UJFkxMDzuVfDXNr/r0Vvab8sP67KjwIymZWb4g MKXCfr1t2jddET/kvQrLLuikCYiF+C+wxIcOW9AsHnfy7vMXQSbigwLpKvTJKgezqEasfH9Y7gyf4 QYg4nvBnqZaLGw==; Original-Received: from [87.69.77.57] (port=3901 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7FvR-0007MD-Io; Fri, 01 Jul 2022 08:39:09 -0400 In-Reply-To: <25F8DA8E-0C2B-4996-9DB0-E89BDE81C924@gmail.com> (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Fri, 1 Jul 2022 13:44:26 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:235799 Archived-At: > From: Gerd Möllmann > Date: Fri, 1 Jul 2022 13:44:26 +0200 > Cc: monnier@iro.umontreal.ca, > larsi@gnus.org, > psainty@orcon.net.nz, > Emacs-hacker2018@jovi.net, > 45898@debbugs.gnu.org > > I have medium_line.json now, and I see slowness (with truncate-lines nil and font-lock), after finding the file and doing random things. What "random things" did you try? > Is it sufficient to do just that for some time while tracing? Yes, I think so. > Do we have some Lisp code to automated this, and make it more reproducible? Possible, but we need to discuss first which commands such Lisp code will invoke. Each command that involves the display code has different CPU processing requirements, and thus reacts differently to such files. > Or, even, should be do truncate-line t first, and without font-lock? That's the next step, I think. In general, you can look in so-long.el for the list of features we found to be expensive in files with long lines; font-lock is just one of them. As for truncate-line, IME it sometimes makes redisplay faster and sometimes slower. I guess the slower cases are where font-lock is the main culprit, since it doesn't stop at the window edge. > (Did someone else observe it being fast at first, and then later slowing down?) That is what normally happens, and the effect on different commands is different, unsurprisingly. For example, with C-n I see consistent slowdown as I go deeper and deeper into the file, and around 20% I start getting "too long to redisplay" errors if I set max-redisplay-ticks to 400,000. By contrast, C-v's performance seems to be much less affected by the position where I invoke it. Still, it becomes slower as I move forward: about 3 times as slow at 30% into the file as it is at BOB. The difference is almost certainly due to the fact that these commands use different methods provided by the display engine code to do their jobs. In particular, C-n calls vertical-motion, which begins by going back to the previous newline, and then comes back by moving the display iteration. Which in this case means it traverses all the text from BOB to where you invoked C-n.