From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: treesitter local parser: huge slowdown and memory usage in a long file Date: Mon, 27 May 2024 15:03:37 -0700 Message-ID: <6D101DD5-6201-4CA6-A105-28A6DA32C3DF@gmail.com> References: <2DB11528-C657-4AC1-A143-A13B1EAC897A@gmail.com> <0132CFC2-CFA0-4D58-9632-6E6E03FE57DB@gmail.com> <8E3466C4-0875-4187-ADC3-5C72FF23A24F@gmail.com> <81dab46b-dba3-45d0-b509-1d40f4b116bf@gutov.dev> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33525"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Ergus via Emacs development discussions." To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 28 00:04:32 2024 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 1sBiSF-0008Uq-W9 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 May 2024 00:04:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBiRj-0001RQ-OZ; Mon, 27 May 2024 18:03:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBiRe-0001QY-Py for emacs-devel@gnu.org; Mon, 27 May 2024 18:03:54 -0400 Original-Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sBiRd-0002Kh-2P for emacs-devel@gnu.org; Mon, 27 May 2024 18:03:54 -0400 Original-Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1f4a5344ec7so1434505ad.1 for ; Mon, 27 May 2024 15:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716847430; x=1717452230; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=k/ubMlo2YNkg+4cAZ2MZsGL9eJB9+ZcA9EZn2FwYA44=; b=jFK/XTtIsLF6q4rTkUuEZpPxHI7NJZy95deAmu0uU7L5lpxX5aVyFyv2puuAKh/tCv 4/KotCtEM4f+MdIf+8pCxfYxNoZd0NOUhqTfFGdVXs7Q4wnyu6QN8XcUwnb3X5GcDY0t iMon+Cc7VNqOQq7IdPwmbzGxDAjEQlyVYkNohxK8ZbWEfDYDYb6dkfCBoKZu6wHiAVpR +DeRgVNL4XvtFIoqLizxN8s9j9K6rxeuW8kdlJlBA77i71Y5dmgeSzQFD6us69oadqHz FNXbSv3YzrMBNKuFDKNyOumOtn8otz4+qhh8glrohP8TlnSqH/AvJgeC2NTbXEkR9VEN N3Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716847430; x=1717452230; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k/ubMlo2YNkg+4cAZ2MZsGL9eJB9+ZcA9EZn2FwYA44=; b=eQ5FLfeuIUglC7U90C2Sx8LIB8zKQVSMNC9qDsWv8Fli9Saa63ExOFtdgmTmoVz4vb GC8mc8h3B0ZjaUXDS1J73GFka0sLNIXdthwZ4TfUN/MQt/C5+IoYzBZVAu1mtGCVN5RR iZspbWB0rFpIegdYmTOM/q4XCSpZZVGb6XPRgIp8B7tXMQ3F+22xflAtY052hsORkpGb wxp0+GwZRYCuPZLsS2L2qkmmBuS63+Z1fd1wxmaNqMsm0ss4cf0Uuhm1fqtKUCTkAbsk 1M1P/BWMAez392CpFEATSpfjTNv0qaIFEBDEz+C6opMCdw7S4RU4Cu1woRgkMOmJYZUB rmsQ== X-Gm-Message-State: AOJu0YyiKejnFQUGOiJshB8b8oR1LshwzKsvB4+LIABuybE4B/fl2B0h C46IRW/uSu/dA8NJFS3BWMxJxK1YPNlDhofwpH8r16rTfIbf9vSeofZvFw== X-Google-Smtp-Source: AGHT+IGa+IyhO4TF6L2nWUvOzB4BItKhIj2ycTfk6XJsPWYeumMCCwqNxcXmDhSZl5guvqUwAQMD2g== X-Received: by 2002:a17:903:1111:b0:1f2:fe12:b7be with SMTP id d9443c01a7336-1f339f602b9mr183367515ad.32.1716847430043; Mon, 27 May 2024 15:03:50 -0700 (PDT) Original-Received: from smtpclient.apple ([2601:641:300:4910:3097:2bb7:97eb:9759]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f44c99e9a7sm67826415ad.216.2024.05.27.15.03.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2024 15:03:49 -0700 (PDT) In-Reply-To: <81dab46b-dba3-45d0-b509-1d40f4b116bf@gutov.dev> X-Mailer: Apple Mail (2.3774.600.62) Received-SPF: pass client-ip=2607:f8b0:4864:20::62d; envelope-from=casouri@gmail.com; helo=mail-pl1-x62d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319630 Archived-At: > On May 22, 2024, at 4:42=E2=80=AFPM, Dmitry Gutov = wrote: >=20 > On 22/05/2024 08:51, Yuan Fu wrote: >>> This listener would be specific for a particular consumer. In our = case, we'd have a listener which would populate - and then update - the = variable used by treesit--pre-redisplay. That variable would store the = "up to date" list of updated ranges. The listener, on every call, would = "merge" its current value one with the new list of ranges (*). = treesit--pre-redisplay would use the data in that data structure instead = of calling treesit-parser-changed-ranges, and set the value to nil to = "reset" it for the next update. >>>=20 >>> (*) So real "merging" would only need to be performed when listener = fires 2+ times between the two adjacent treesit--pre-redisplay calls. = Otherwise the current value is nil, so the the new list is simply = assigned to the variable. Anyway, the merging logic seems to be the = trickiest part in this scheme (managing and interpreting offsets), but = it should be very similar in both approaches. >> I agree. The usefulness of treesit-parser-changed-ranges aren=E2=80=99t= really justified at this point (well, except that it makes the = caller=E2=80=99s code much easier to follow). >=20 > That it does. >=20 >> Let me implement what you described and let=E2=80=99s see how it = goes. >=20 > Thank you, looking forward to it! >=20 >> I think we don=E2=80=99t even need to merge the ranges (which will be = prone to bugs if I were to write it =F0=9F=98=89, we can just push the = new ranges to a list and later process them one by one. >=20 > I think this might amount to the same thing (merging when generating, = or merging when processing). It seems there will also be a small issue = of "kinds" of ranges?.. >=20 > Like for example suppose we have two consecutive operations which = insert new characters in range 200..300. The result should be a range = that spans 200..400, right? >=20 > But if one operation just changes text in that range (keeping its = length intact, e.g. capitalizing the whole region), and another does the = same (back to lower case), then the combined range would remain = 200..300. >=20 > Computing that might be difficult without having access to the kinds = of changes are being done (does tree-sitter report those?). OTOH, most = of the time the most important part is the position of the beginning of = the changes (e.g. for syntax-ppss), and we could treat the rest of the = buffer as invalidated=E2=80=A6 Oh you=E2=80=99re absolutely right, the range will be shifted by later = edits in the buffer. It=E2=80=99ll be hella hairy to keep track of all = that=E2=80=94say the previous changed range is (100 . 200), and user = inserted 50 chars in position 150, we need to account for that and = update the range to (100 . 250) before merging the new updated ranges = with this one.=20 So it seems the best way is really to move treesit--pre-redisplay = entirely into the primary parser=E2=80=99s notifier, WDYT? Yuan