From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Fri, 5 Aug 2022 15:08:22 +0300 Message-ID: References: <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.org> <83v8rf5894.fsf@gnu.org> <65cb7c73fd4a999cca00@heytings.org> <8c7321f2f3400a5db9be@heytings.org> <8c7321f2f388e5343475@heytings.org> <8c7321f2f36494299e61@heytings.org> <8c7321f2f336523624e3@heytings.org> <83r1202meh.fsf@gnu.org> <6020ffaf-9069-0070-76cf-a13379ef01b5@yandex.ru> <83les71ilg.fsf@gnu.org> <06c5560d-3009-e5a5-3d33-fe5d2ec32d6b@yandex.ru> <74ddc877f17a06d8f120@heytings.org> <100d08b3-c25b-683f-6def-39052107ab59@yandex.ru> <83h72r16g1.fsf@gnu.org> <640c2e07-98e1-96d6-bb02-19f5f03f637f@yandex.ru> <834jyq29o1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10366"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 05 14:09:15 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 1oJw8h-0002YQ-1u for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Aug 2022 14:09:15 +0200 Original-Received: from localhost ([::1]:54228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJw8f-0007rC-Pz for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Aug 2022 08:09:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJw8U-0007nf-Nr for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 08:09:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38502) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJw8U-0003Qv-FS for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 08:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJw8U-0005mW-BF for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 08:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Aug 2022 12:09:02 +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.165970131722188 (code B ref 56682); Fri, 05 Aug 2022 12:09:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 5 Aug 2022 12:08:37 +0000 Original-Received: from localhost ([127.0.0.1]:56483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJw85-0005ln-3i for submit@debbugs.gnu.org; Fri, 05 Aug 2022 08:08:37 -0400 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:46806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJw80-0005lW-8K for 56682@debbugs.gnu.org; Fri, 05 Aug 2022 08:08:35 -0400 Original-Received: by mail-wr1-f54.google.com with SMTP id l4so2985994wrm.13 for <56682@debbugs.gnu.org>; Fri, 05 Aug 2022 05:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3F6gNYuppM2ig+gRRPJTWizD34aVrlhYiRD7DuQgu6Q=; b=Sks/7W91SSkClfQWeteOhWwjW0TBieUbbnUXNm3hleO1V1aHt9ZH4jr81NgU5ROvpF siw5O95mkq+S/98vhTw3itS4AqE7npMzHv0NU7IIjZ7YFQe8ltuOfGtCnqaT6i3XdV/D PehLBWdT67o0CL7tvgcwtRLfPeiZfkho6/lkkDMDvuT5klya+hn9EtNxseedC6v31sRX dcQVOy3cvbpr7z+RRwE9p97R0yu/AINJS1uD7wwrA4dlWiOqZsUsrTJPmKX7OYF/IhSi H3WtursKhD5BqYbAGTCjKGuENVL0jenUFyNXGCRpt1ujoJ3qTZVDdKr4gpFb/Wf2wWf2 24Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3F6gNYuppM2ig+gRRPJTWizD34aVrlhYiRD7DuQgu6Q=; b=evb6Z2zWFeydgom33h1eqnv8X1Favq+rUZ3wvbNVXWgld7igCvnqNHJ55VUbhrjEKW cS41pZ+ccI9gy82VIImutq7FXOVMH12+DJAZl+r7tN8ZVAB9NwiGoByC6Z8xhj9JXSyN dxhPyj5FbubbC+ybCAty3iPW2HCoqlc2t0bRyGPT0MNQ4/nfJdy2RddpD9sQHhgzJB2v Z/Nz4NJsXPiCpGdw3UtWDiKzuD1bBFeGlayk9WqiZlY+VUSlBAv9z18u0ffb7mQGEGWP YKLDB3oYHsnlh7H+XG1k1tWJiAnUPU0df5VtlFRmUZ37/p1kJwT7h2Fdl2T3V0RhtmHn B6DQ== X-Gm-Message-State: ACgBeo1nCOVC2ubbyPbhhCZ7HV0HuYnboIeR/LlEdRi0Yi+8bdfiRNfQ RCmx++mJdZXJXvS5rroayns= X-Google-Smtp-Source: AA6agR7CeQGE9OPxmikpUbVIO3m9JzKkNnWXK6Qq3339wHgExrSkfTHUxxib0VcXjRU3hVG8DGplBQ== X-Received: by 2002:a5d:6489:0:b0:220:6399:c7c8 with SMTP id o9-20020a5d6489000000b002206399c7c8mr4301919wri.655.1659701306312; Fri, 05 Aug 2022 05:08:26 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h19-20020a05600c351300b003a501ad8648sm4672103wmq.40.2022.08.05.05.08.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Aug 2022 05:08:25 -0700 (PDT) Content-Language: en-US In-Reply-To: <834jyq29o1.fsf@gnu.org> 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:238880 Archived-At: On 05.08.2022 14:48, Eli Zaretskii wrote: >> Date: Fri, 5 Aug 2022 14:34:12 +0300 >> Cc: gregory@heytings.org, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca >> From: Dmitry Gutov >> >> We really have different problems and thus need different solutions for >> them. Not just one blunt instrument. > > The current opinion of both the head maintainers and of Gregory is > that these are all parts of the same problem, and a single class of > solutions can solve most of them. This kind of approach fails to optimize for the behavior in medium-sized files, like the downloadify.js I showed previously. Simply customizing long-line-threshold to a much higher value will bring back redisplay stutters on C-n/C-p/etc, which *were* a real problem that some of Gregory's changes solved. > The problem being that many > portions of Emacs code involved in navigation and redisplay don't > expect lines to be too long, and therefore employ algorithms that > don't scale well with line length. As I demonstrated, font-lock itself doesn't have that issue. Furthermore, the performance problem with syntax-ppss which we are talking about now doesn't have anything to do long lines. Go ahead and pretty-print dictionary.json (you can use 'M-x json-pretty-print', write the buffer to a new file, then re-visit it). There won't be any long lines in the resulting file, but 'M->' will still make you wait a few seconds the first time. > Preventing such code from going > far back to the beginning of the previous line, and then coming back > through all that text, is therefore an idea that should appear very > reasonable. It also works surprisingly well in practice, at least > according to what we know at this point. > > I get it that you disagree, but I haven't seen any real data behind > your dissenting opinions, and thus I don't yet see any reason to > reconsider changing the direction of development in this regard. I don't understand why you dismiss the more subtle approach which still seems to reach the stated goals. Gregory's changes, along with my suggested tweak, indeed bring work "surprisingly well" already. All without breaking font-lock in the common case. Like, we're going from a 255 (?) second delay to 2 second delay already without breaking fontification. And yet you're eager to go from 2 seconds down to ~0 and sacrifice highlighting correctness?