Re: Tree-sitter integration on feature/tree-sitter

[Eli Zaretskii <eliz@gnu.org>]

> From: Yoav Marco <yoavm448@gmail.com>
> Cc: Yuan Fu <casouri@gmail.com>, 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.