From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Tue, 02 Aug 2022 18:04:30 -0400 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> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8573"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56682@debbugs.gnu.org, Eli Zaretskii , Dmitry Gutov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 03 00:05:22 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 1oJ00u-0001ys-IO for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Aug 2022 00:05:20 +0200 Original-Received: from localhost ([::1]:42410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJ00t-0003PA-Aa for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Aug 2022 18:05:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJ00d-0003O6-Ek for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 18:05:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55600) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJ00c-0005UR-Re for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 18:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJ00c-0003lE-Gg for bug-gnu-emacs@gnu.org; Tue, 02 Aug 2022 18:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Aug 2022 22:05: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.165947789214435 (code B ref 56682); Tue, 02 Aug 2022 22:05:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Aug 2022 22:04:52 +0000 Original-Received: from localhost ([127.0.0.1]:45349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJ00S-0003kk-Cj for submit@debbugs.gnu.org; Tue, 02 Aug 2022 18:04:52 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJ00N-0003kU-8n for 56682@debbugs.gnu.org; Tue, 02 Aug 2022 18:04:51 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8AC614421F9; Tue, 2 Aug 2022 18:04:41 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F11464421F8; Tue, 2 Aug 2022 18:04:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659477875; bh=N47+m5J8OZo5RlwH3UT50naH14YF83VoJqeMLYIHZw0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Orwu46cw5W9p1leqbI99HgQJqsFlkKfK2q+QYOkNO7aGEzyDyGzbGLQiOEdd3PtKs A1E5dpc6S4POGBzFXVSo095gAs1YMamF67ed+kSFGJbYZy0YOsjoUm0zIfbWHEkZTK HHOIuJP7T+BNl/PE7T7olq4LdzNECtRv8lOcKGUDCkaxXDqRsiYAJsxKOS5Htw4LRw /mcX2zX9uNL/7nRi7Bc3z/A2BPpQ5Ln5Blwq/pL2IXBmoZqpabEEtBq30LW/v6fXiq YhXaKmblg2LlB6fJlyz3XshkgS6gDkJ02ukyx5oYJLTHRtb854ZAuw8jymhlFi2qeK aOfHpkKWfJP+A== Original-Received: from milanesa (unknown [46.44.221.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F025C120476; Tue, 2 Aug 2022 18:04:34 -0400 (EDT) In-Reply-To: <74ddc877f17a06d8f120@heytings.org> (Gregory Heytings's message of "Tue, 02 Aug 2022 14:57:25 +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:238594 Archived-At: >> Another piece of the puzzle was added by Stefan in 15b2138719b340. > That looked promising, but sadly it had only a very limited effect. FWIW, that was also my experience :-( >> So perhaps we should re-evaluate the testing scenario to see where the >> current bottlenecks are. If we current main issue is the 55s spent in >> syntax-ppss, a more constructive approach would be to look into optimizing >> parse-partial-sexp. Or even give up on certain scenarios, admitting that >> waiting 55s once to visit the end of a 1 GB buffer is not so bad (and that >> could part could also be sped up by setting syntax-propertize-function to >> nil and using a very simple syntax table, for instance). Those 55s were with a `syntax-propertize-function` set to nil already. We could do a bit better in some modes, tho, e.g. in fundamental mode no char has string or comment syntax, IIRC, so we could arguably make `syntax-ppss` return a value without parsing anything at all (except that `syntax-ppss` is also supposed to count parentheses, which *are* present in fundamental-mode). > It is bad, especially now that it became clear that in fact it's not > "waiting 55s once" but "waiting 55s each time the buffer is modified and you > move to another position in the buffer". Actually, if 55s is the time it takes from BOB to EOB, then the time for "change at POS1 plus move to POS2" should be approximately 55s * (POS2 - POS1) / (buffer-size) -- Stefan