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

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 11 May 2022 13:14:33 -0700
> Cc: Yoav Marco <yoavm448@gmail.com>,
>  emacs-devel@gnu.org
> 
> >  |   |                                      | 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".
> 
> I think that’s just a way to run font-lock enough times without repeatedly 
> fontifying the same region?

Then I'm not sure the result is very interesting by itself, unless we
can find a way to use that result for estimating how long will it take
to perform fontifications in some practical use cases that we care
about, and compare that to what we have now in those use cases.

> I redid the benchmark, but without his reuse patch, just to see how much time 
> is spent on creating query objects. So fortifying 40 lines for 463 times 
> takes 6.92s (according to Emacs, 7.30s according to the profiler). That 
> counts to 0.0158s per call to font-lock-region, of which 0.0104s is spent on 
> creating the query object. That seems to tell me if we optimize away the 
> query object creation we can make font-locking very very fast?

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.

> 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.

> Benchmark 3: fontify all of xdisp.c, 40 lines at a time.
> took 88.28, of which 5.00 is GC (4 gc runs), loop count: 905
> 
> font-lock: 88.28s -> 0.1997285067873303 / loop

So we already have an order-of-magnitude speed-up with tree-sitter: we
go from 200 msec down to 16 msec.  Also, 200 msec is above the
threshold of human perception of a response delay, whereas 16 msec is
way below that threshold.  With such significantly faster font-lock, I
wouldn't bother caching anything, at least not yet, not unless someone
comes up with a practical use case where the query-compilation part
really makes a significant practical difference in terms of absolute
response times.

Bottom line: I think the 6-msec speedup (from 16 to 10) in the
scenario that was used in these benchmarks doesn't justify the
complexities of caching the queries, given the overall excellent
performance we get with tree-sitter.  Caching is an optimization, and
in this case it sounds like doing that now would be a premature
optimization.

Thanks.