Re: Why tree-sitter instead of Semantic? (was Re: CC Mode with font-lock-maximum-decoration 2)

[Eli Zaretskii <eliz@gnu.org>]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Wed, 10 Aug 2022 06:05:56 -0400
> Cc: Po Lu <luangruo@yahoo.com>, Alan Mackenzie <acm@muc.de>, emacs-devel <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
>  It is simply too slow to be a modern solution for these features.
> 
> Can you (or anyone on the list) provide a more detailed analysis?  Is the slowness inherent in the algorithm
> design, the implementation method (eg table driven parsing designed before the availability of the native
> compiler), the basic synchronous nature of ELisp, the impact on garbage collection, etc?

I don't have this information.  Maybe someone else does.  But in
general, it is a very small wonder that a parser written in optimized
C is much faster than anything written in Emacs Lisp, given that Lisp
is an interpreted language that has no special support for writing
parsers.

> If the analyzer were run in a second emacs process using mmaped files to share buffers being analyzed,
> then communicating the results either via LSP or some other channel, would that make it usable?

I doubt that.  In particular, LSP-style communications are a cause of
slower operation, not faster operation.  Various LSP-based packages
tolerate that because the server can do stuff clients cannot easily do
without investing a lot of language-specific efforts and expertise.

> I've definitely noticed more pausing with Semantic turned on, but it's not unusable so far (but I'm also not
> looking at any C++ source, just ELisp and C, maybe some shell scripts, info files and Markdown).

I didn't say Semantic is unusable.  It certainly is usable.