Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Perform parsing off the main thread when Tree-sitter is enabled #17339
Currently, all parsing in Atom takes place on the main thread, whether you're using the new Tree-sitter system or the default TextMate system. In some circumstances, parsing can take long enough that it reduces the app's responsiveness. This PR makes it so that when you've enabled Tree-sitter, parsing will take place on a background thread so that it can never delay UI responses.
This will also improve Atom's overall parsing speed, because the native parser is now reading directly from the native
Another interesting twist: parsing asynchronously is great for Atom's frame rate and responsiveness, but can cause Atom to do more work overall (bad for battery life) because for many edits, it has to render twice: once immediately after the edit, and then again once the parsing completes in order to update the syntax highlighting.
Here's a flame graph of this behavior:
I've just added a refinement to the algorithm to address this. Now, we perform a limited amount of parsing work immediately on the main thread. If this completes, we can re-render with the correct highlighting from the start. Only when parsing takes a long time do we need to do it in the background. The underlying Tree-sitter API is described in this PR.
Here's the new flame graph for the same editing action as above (the scale is different):
Parsing and resolving the parse promise only took half of a millisecond, so it's better for the user's energy usage to finish the parse up front and render only once.
The amount of synchronous work that we allow the parser to do is specified as a number of abstract 'parsing operations'. These don't correspond directly to any unit of time, but they just serve as a rough way to limit the the work we do that has very low overhead to keep track of.
I've currently hard-coded it to 1000 parsing operations. If we want, we could do something more sophisticated like measuring how long parsing operations take on average on the user's machine and tuning the limit appropriately. I don't think the exact number is too important though. We just want some limit on the amount of synchronous work we'll do.