pulsar-edit
Tree-sitter rolling fixes, 1.128 edition
Had a couple already in the hopper just from the last couple of days.
JSON plus comments! Big deal! Should've done it ages ago!
Release day nears, so I suppose it's time to take this out of draft!
Status: I am reading the quite large commit message and its associated diff, taking breaks for food, etc. It may be a bit before I post more.
Status: I am reading the quite large commit message and its associated diff, taking breaks for food, etc. It may be a bit before I post more.
Fire a signal flare every 12 hours so I know you're still alive.
The big slowdown seems to have gotten much faster to resolve (and happens much more interactively rather than locking up the window's whole renderer thread for one huge continuous stretch) when launching Pulsar with a large MarkDown document open, or when activating a language package with such a document open. Assuming it is being parsed as MarkDown and not set to Plain Text which skips the problem entirely.
👍
But yeah, I feel that's a decent way to report some meaningful feedback/review of the big ol' commit that was.
The big slowdown seems to have gotten much faster to resolve (and happens much more interactively rather than locking up the main thread) when launching Pulsar with a large MarkDown document open, or when activating a language package with such a document open. Assuming it is being parsed as MarkDown and not set to Plain Text which skips the problem entirely.
I'm thrilled you still have the original conditions available so you can verify this fix.
Oh yeah, just booted up Pulsar 1.127.1 again (without this PR's fixes) and it is doing the full-on slowdown again, so at least from very brief testing (two boots, disabling/re-enabling a language package once) this PR is making a very big difference.
@DeeDeeG hollered uncle (and fairly so) on having to read that long commit message. Just to make life easier for our future selves, here's a summary of those changes that spares you from my long-windedness:
- When you re-open a project, you've likely got some files open already. It's hard to restore syntax highlighting on those files while grammars are still being activated… but it's something we have to do anyway, since new grammars can be activated at any time.
- Suppose you're reopening a project with a Markdown file open. We'll syntax-highlight the file as soon as the Markdown grammar is activated. In the general case, there's no good reason to wait longer than that.
- But you might have lots of fenced code blocks in your Markdown file, and those are handled as injections. The first highlighting pass might've happened before some of those grammars were ready. So as other grammars activate themselves, we might need to re-highlight the file to reflect our new capabilities.
- On current
masterwe're using an extremely blunt tactic: re-process all injections whenever almost any grammar is activated — it just had to be a modern Tree-sitter grammar and be injectable. That's why startup can be so slow for certain kinds of documents — to the point of long freezes. - On this PR, we're trying very, very hard to skip doing that extra work. Even a bunch of bookkeeping to determine whether that work needs to be done… is faster than doing that work needlessly.
- The new approach is to visit each language layer in turn (with an optimized data structure that helps each layer more easily keep track of its child injection layers) and see if the new grammar would've been used instead of the grammar we used last time. We also keep track of the previous update's failed attempts to find grammars (often because they weren't activated yet!) and see if this new grammar would've been used for any of those. If so, we re-parse and re-highlight the layer; if not, we skip it.
- This makes us much smarter about when to re-parse and re-highlight in response to grammar activations on startup. A freeze of ten or more seconds (enough to make the “we think we're frozen” dialog appear) was, in practice, reduced to under 1 second in the worst case.