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.devel Subject: Re: treesitter local parser: huge slowdown and memory usage in a long file Date: Mon, 12 Feb 2024 16:09:10 +0200 Message-ID: <864jedsrjt.fsf@gnu.org> References: <5991618.MhkbZ0Pkbq@fedora> <93F7DE13-0EC7-4A17-89B1-E07C99C6347B@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="16965"; mail-complaints-to="usenet@ciao.gmane.io" Cc: v.pupillo@gmail.com, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 12 15:10:01 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 1rZX0S-00049V-Ul for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Feb 2024 15:10:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZWzm-0000mo-8w; Mon, 12 Feb 2024 09:09:18 -0500 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 1rZWzj-0000mJ-Al for emacs-devel@gnu.org; Mon, 12 Feb 2024 09:09:15 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZWzj-0001wG-2E; Mon, 12 Feb 2024 09:09:15 -0500 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=tlw/w5g/dA2vb7dLk7TVGoMu4F0f4G+ECr2u9j9OmaU=; b=p+Meo6vIMAxMvrQ1y4yw J5k6HALtmCxVYK14nPiVmqu/LtysgVxxvUjlBlfGCmL2ZbXmpRWhQ7Hl0hrORjwwapcopUnFWItHP lq/4PujnNZ3dY5akoOuqapEEdmZHHKojJHcPXtfl2K+cVWPCmlg+w9yEaaq3iw0AAod5Dhccx0/+P cnAQW0e0RvFqyszfFxOF7/Sd7fs3v7RCeQ91GfOHcr1hZ8qGXuwVNt7Sm7oA7StUXjRC0WCzGv5Lp G9nHULvSVqeII0OcD++NDUHIuqyK/1aI+KpwbUw7HLdkR/U7InjFoXYU2CDRfj0nQtrPT4j9w7bbW TF2+AiQON5qrvQ==; In-Reply-To: <93F7DE13-0EC7-4A17-89B1-E07C99C6347B@gmail.com> (message from Yuan Fu on Sun, 11 Feb 2024 20:16:11 -0800) 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:316135 Archived-At: > From: Yuan Fu > Date: Sun, 11 Feb 2024 20:16:11 -0800 > Cc: "Ergus via Emacs development discussions." , > Eli Zaretskii > > Thanks, the culprit is the call to treesit-update-ranges in treesit--pre-redisplay, where we don’t pass it any specific range, so it updates the range for the whole buffer. Eli, is there any way to get a rough estimate the range that redisplay is refreshing? Do you think something like this would work? > > (treesit-update-ranges > (max (point-min) (- (window-start) 1000)) ; BEG > (min (point-max) (+ (or (window-end) (+ (window-start) 4000)) 1000))) ; END > > I guess the window-start would be outdated in pre-redisplay-function... The problem is that window-start is not guaranteed to be up-to-date when pre-redisplay-function is called: the window-start is updated by redisplay, and pre-redisplay-function is called before the update. Moreover, pre-redisplay-function could be called either once or twice in a redisplay cycle, and window-start is up-to-date only for the second call. The window-end point is basically never up-to-date during redisplay, only at its very end. So my suggestion would be to define the range from position of point, using the window dimensions; see get_narrowed_width for ideas. This could lose if the buffer has a lot of invisible text, so I suggest to check for invisible properties, and if they are present in the buffer, punt and use the whole accessible portion of the buffer (I don't expect PHP buffers, or any buffers in programming-language modes, to have invisible text).