Hi Ihor,

> I am wondering how the third-party parsers are going to scale for larger
> Org files. I did some simple testing in the past, and it seems that only
> tree-sitter can potentially get sufficiently close to org-element in
> terms of performance.

I’ve actually had a brief look at my performance using my Emacs config file
(which is ~10k lines). On this, my parser is about ~5x faster than org-element.
On a smaller file like the project’s readme it’s closer to ~10x faster. I’ve
also noticed that I can multithread the parsing, which produces a ~9x speedup on
my computer. So, that would be ~40-90x faster than org-element. I have yet to do
much profiling/benchmarking/optimisation though, I’m still in the “feature
adding” phase. This means that it could well slow down as I add more for it to
recognise, but there are probably also unrealised potential performance
improvements.

> Maybe we should implement a Elisp LSP server instead of many individual
> parsers in different languages?

For the sake of tools that operate on Org files, not just the Org editing
experience, I think it’s quite good if we have a selection of /good/ parsers
available for different languages. However, I also think an LSP server would be
good. That’s why I have <https://github.com/tecosaur/org-lsp>, even if I haven’t
spent anywhere near as much time on it as I would like (it’s barely a skeleton
at the moment).

> tree-sitter vs. org-element on 15M Org file

Might you have a link to this file? I’d be interested to try it.

All the best,
Timothy