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: Tree-sitter integration on feature/tree-sitter Date: Wed, 11 May 2022 19:27:36 +0300 Message-ID: <83ee10qbk7.fsf@gnu.org> References: <87y1zabmbt.fsf@gmail.com> <5F186EBD-CD21-422B-8B4F-0D5424173334@gmail.com> <875ymdwf76.fsf@gmail.com> <011DA1A3-0FA8-4449-878A-FD6B336B0F1B@gmail.com> <8735hhw75p.fsf@gmail.com> <83czgks4ss.fsf@gnu.org> <87wnesuw63.fsf@gmail.com> <83pmkkqhft.fsf@gnu.org> <87tu9wukbt.fsf@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="10627"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org To: Yoav Marco Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 11 18:28:29 2022 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 1nopCP-0002eq-0u for ged-emacs-devel@m.gmane-mx.org; Wed, 11 May 2022 18:28:29 +0200 Original-Received: from localhost ([::1]:49898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nopCN-0005gW-QD for ged-emacs-devel@m.gmane-mx.org; Wed, 11 May 2022 12:28:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nopBX-0004yb-H2 for emacs-devel@gnu.org; Wed, 11 May 2022 12:27:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44792) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nopBX-0000Jq-7T; Wed, 11 May 2022 12:27:35 -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=1uJEBHs6gRQqBpCD/uBz6sC80z+zaoqq17cBrXrd9BQ=; b=cTcZ7Pmum2LIE4q9K+ec pBxx0c+iBORkR7lZ2sFHukUE3qCZCzaH1KBQ+d/iflsNMMCRqSleuN8iFJtpSN07zoVqL22rBRpK6 OJgxAV0bTBECTI2wTgFxT99XguieBvhho56VMgRUX5vP/AU7Ul1rgJ236PG2C4xs6k0YgkPBO0nAc D9T7PNXyrqJ7bFJV4Yw/YkJjDL7B3BHsLuABW7PsiQC4jsHmCAL0rB4aPWQugLjz3wXYlJuu2rSoY JiVYI9bRhL0KGQau+7Y4DdTRi4U18tzyrYAtq9kkzVBDef7/jYUOouaomJiMjqYutKtws/9ttl0xV m5n66WhBQhV14Q==; Original-Received: from [87.69.77.57] (port=4469 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 1nopBW-0002ys-Kt; Wed, 11 May 2022 12:27:34 -0400 In-Reply-To: <87tu9wukbt.fsf@gmail.com> (message from Yoav Marco on Wed, 11 May 2022 18:40:24 +0300) 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" Xref: news.gmane.io gmane.emacs.devel:289642 Archived-At: > From: Yoav Marco > Cc: casouri@gmail.com, emacs-devel@gnu.org > Date: Wed, 11 May 2022 18:40:24 +0300 > > > So let's start with the benchmarks, and please tell what exactly did > > Emacs do to trigger fontifications in each benchmark. > > I called treesit-font-lock-fontify-region, which is the main function > used for syntax highlighting in treesit as far as I'm aware. > It's the value of font-lock-fontify-region-function after calling > treesit-font-lock-enable. > > (The code's attached in the original mail) And the timings are in the table below? | | | no reuse (now) | reuse | | 1 | Fontify xdisp.c all at once | 0.01s | 0.01s | | 2 | Fontify 60 next lines of xdisp.c ×10 | 0.10s | 0.00s | | 3 | Fontify 60 next lines till the end | 6.06s | 0.01s | If so, what is the significance of the last line in practical use cases? JIT font-lock never fontifies such large chunks of source code, it does that in 512-character chunks, which is less than 60 lines in most cases, and definitely not "till the end". Also, how much time does it take to do the same with the current regexp- and syntax-based font-lock, for the same chunks of text? We need to examine the use cases and the absolute numbers carefully before we conclude that any kind of caching is needed and/or justified. Thanks. P.S. If the above table is not the relevant benchmarks, please show the URL of the message in the archive where you posted the relevant benchmarks.