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#56682: Fix the long lines font locking related slowdowns Date: Thu, 28 Jul 2022 19:48:48 +0300 Message-ID: <83pmhp89ov.fsf@gnu.org> References: <837d46mjen.fsf@gnu.org> <174616cd5c33bfc14b1f@heytings.org> <837d44jr4p.fsf@gnu.org> <83bktghrn0.fsf@gnu.org> <8a3eaeef010995a5da8d@heytings.org> <837d40ds09.fsf@gnu.org> <83zggwcby5.fsf@gnu.org> <83o7xccagi.fsf@gnu.org> <831qu7daxb.fsf@gnu.org> <83sfmnb7yg.fsf@gnu.org> <837d3ybh5z.fsf@gnu.org> <136c4fe0fc74196714aa@heytings.org> 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="35702"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 28 18:49:19 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 1oH6hK-00096G-Ns for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Jul 2022 18:49:19 +0200 Original-Received: from localhost ([::1]:46752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oH6hI-0008E6-PR for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Jul 2022 12:49:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oH6h5-0008Dh-C1 for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 12:49:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41334) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oH6h5-00050o-3G for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 12:49:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oH6h3-0003bC-UG for bug-gnu-emacs@gnu.org; Thu, 28 Jul 2022 12:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Jul 2022 16:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165902692913809 (code B ref 56682); Thu, 28 Jul 2022 16:49:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 28 Jul 2022 16:48:49 +0000 Original-Received: from localhost ([127.0.0.1]:59316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH6gq-0003af-PG for submit@debbugs.gnu.org; Thu, 28 Jul 2022 12:48:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oH6go-0003aQ-QU for 56682@debbugs.gnu.org; Thu, 28 Jul 2022 12:48:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52154) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oH6gi-0004yF-Ln; Thu, 28 Jul 2022 12:48:40 -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=tI+tsDe5ahSVx+bC3x0ytIOxDgTO1q95fz+XSZwS3s0=; b=D4YM9KrIx3KC1dtpZnfP I2a350r9sG5Kh4FyS2HlxXSFuT4Yk4PFEwYu+qAnkw3Qr0ACt68xbwodqnvNbN/4eF+jnVRoZQFdw OjT6oOCfZiDMPp9vl+5ndD5kq5VvNwBsaWnqHhz88i6vE2tz0Tz689UiYZZ4VKeBA1QjvriZ1+YNv 7IZ3kRRwGvWkcUUmCfoQEOq3KAk8HRWLhR34JDHGB9mujK6CpfXpZKyuyOJUK+FPjkhTsL5bDfH++ omqERPNEpKkIOyqheOizCe2XVx3FOAh9TJFY+hnaH5y8Ba7NH/a5snZV+ms9rs4+hNuEIFVbB7cXm 5sfJcj5KGpcqVQ==; Original-Received: from [87.69.77.57] (port=3868 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 1oH6gi-0007ZF-1l; Thu, 28 Jul 2022 12:48:40 -0400 In-Reply-To: <136c4fe0fc74196714aa@heytings.org> (message from Gregory Heytings on Thu, 28 Jul 2022 16:29:44 +0000) 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:238122 Archived-At: > Date: Thu, 28 Jul 2022 16:29:44 +0000 > From: Gregory Heytings > cc: Gerd Möllmann , > 56682@debbugs.gnu.org, monnier@iro.umontreal.ca > > Indeed, Emacs isn't really usable. For example, with > multiple-long-lines.xml, after M-g g 20 C-e (which already takes several > seconds to complete) each motion, search or insertion command still takes > several seconds (even with find-file-literally). For example (without > isearch-lazy-highlight), C-s RET takes about 10 seconds. > After that, C-s C-s takes another 10 seconds, an additional C-s also takes > 10 seconds, and C-g to abort isearch takes about 90 seconds. And, even > when you don't do anything, Emacs uses 100% of the CPU. All this is, in > the same file, instantaneous without truncate-lines. I think such long lines happen in files that have very little except the long line. So duplicating it makes the use case much less important. And in any case, we shouldn't try dealing with such files before we have a good solution for a single-line files. > > (Searching for " > That's (another sign of) the fundamental problem I mentioned earlier. > Without truncate-lines the visible portion of the buffer remains small, > and it is thus possible to reduce the portion of the buffer that display > routines will see. With truncate-lines it can easily become huge. For > example, with multiple-long-lines.xml, (- (window-end) (window-start)) is > 7744464 with truncate-lines and 2454 without truncate-lines. And > multiple-long-lines.xml is still a relatively "small" file, it's only 15 > MB. This is actually a bug in isearch.el: using window-end in a buffer under truncate-lines is simply wrong. I'm going to file a bug about that soon. But that's not a fundamental problem, or at least I don't yet see why it would be fundamental. It's something specific to isearch.el and to how isearch-lazy-highlight is implemented. The fix I installed prevented us from walking all that long line till the end of the buffer, so in effect the display code doesn't see most of the buffer text, they just jump over it. > > I'll try to think how to speed up these move_it_* calls in those cases. > > Ideas welcome. > > I cannot claim I understand the display code enough, but I see no way to > make the portion of the buffer that is considered by display routines > smaller without introducing the kind of rectangular narrowing I mentioned > earlier. I still have one or two ideas to try, and they don't involve anything as complex as some new kind of narrowing. > Perfect is the enemy of good. I strongly suggest we just admit that Emacs > can't cope with long lines and truncate-lines together, which is true > anyway given the DISP_INFINITY limit. Feel free to give up on it and stop trying to make that case faster, but I'm not ready to give up yet.