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: Thu, 12 May 2022 19:04:06 +0300 Message-ID: <838rr6pwjt.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> <83ee10qbk7.fsf@gnu.org> <8F6A43D1-D1EA-4602-A245-627DB7960FC2@gmail.com> <838rr7qqhw.fsf@gnu.org> <87sfpekf6t.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="11456"; 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 Thu May 12 18:17:46 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 1npBVZ-0002oN-W4 for ged-emacs-devel@m.gmane-mx.org; Thu, 12 May 2022 18:17:46 +0200 Original-Received: from localhost ([::1]:43886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1npBVY-0005pA-An for ged-emacs-devel@m.gmane-mx.org; Thu, 12 May 2022 12:17:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npBIJ-0003DA-Pr for emacs-devel@gnu.org; Thu, 12 May 2022 12:04:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38932) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npBIJ-0008KR-FG; Thu, 12 May 2022 12:04:03 -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=WQxOkki+0fT7OShZvVxAlXWv6gKCQG3/372hjHyjBgY=; b=oE9SXAWg4surAAjtfShR mNo+dpWz4Yg2rwXvaR1oJd71Rd8FfGRmQUulRMJestnLH7+DjjTZc6IQqSVOGpS2V2yGWuHzVR+UG cktjrJUnFt6VFy3hj95pNwjVNyvtO3J6p/ghMP/OxCAeYQ93vNlIl4jum1bVf2sN1g6J0LUIYa5+a 3C6gFaiYVCw5jx8WvrxaQ/H9+jUby3zswD/4kSTrO2S7MzCLVdQQ/jqmf9M4evhHys/3mf2A6RwZT AWZmRhCEHMPMo8xK52zkYBCyuy2iNI8xe9MTCoTljcGknPPhkovImCpE9hR2A1l4RTXbS4SV+Nooi cRWO3R1t1YFrvA==; Original-Received: from [87.69.77.57] (port=3994 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 1npBII-0007py-UI; Thu, 12 May 2022 12:04:03 -0400 In-Reply-To: <87sfpekf6t.fsf@gmail.com> (message from Yoav Marco on Thu, 12 May 2022 17:16:41 +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:289701 Archived-At: > From: Yoav Marco > Cc: Yuan Fu , emacs-devel@gnu.org > Date: Thu, 12 May 2022 17:16:41 +0300 > > And it probably is: in my benchmark, query compilation improved > performance in much more than 16/6=266%: it went from 6.06 to 0.01. That was in one of the tests, which, AFAIU, is not very interesting for assessing the effect on practical use cases in Emacs usage. Or are you saying that Yuan's explanation of what that test tested was incorrect? in that case, please post the correct explanation. > > According to your benchmarks, it is already very fast: 16 msec is a > > negligible time interval. Of course, 40 is a somewhat arbitrary > > number, but to get a less arbitrary one, we should determine it from > > some concrete scenarios, such as the 512-character chunk JIT font-lock > > uses during redisplay, or the number of lines on a typical window > > that's important when one scrolls with C-v/M-v, etc. > > It's easy enough to convert the benchmarks to 512-chars chunks rather > than 40 lines. See table a few paragraphs below. I'm sorry, I don't understand how to interpret that table. Can you please explain the two last entries in the left column? > >> If we expose "compiled query” we don’t need to cache them either. > > > > Then the Lisp program will have to do that, which is even worse, > > because the problems I described will now have to be solved by Lisp > > application programmers, each time anew. > > Will they? They'd just need to compile their queries once, when defining > them or when setting treesit-font-lock-defaults. And decide when to discard them.