When editing, parsing no longer impacts the app's frame rate at all:

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.