Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntax highlighting is SLOW #15

Open
pyrocat101 opened this issue May 3, 2021 · 3 comments
Open

Syntax highlighting is SLOW #15

pyrocat101 opened this issue May 3, 2021 · 3 comments

Comments

@pyrocat101
Copy link

This tool is pretty slow when I tried piping a large diff to it, taking nearly 4 seconds. So I profiled it with perf and found that a lot of time is spent in the WASM library (https://github.com/NeekSandhu/onigasm) indirectly used by https://github.com/shikijs/shiki/.

Screen Shot 2021-05-02 at 21 25 17

If I comment out the usage of highlightSyntaxInLine, then it takes less than 500ms to display the previous diff. This is the perf report:

Screen Shot 2021-05-02 at 21 18 41

Have you considered:

  1. Provide CLI flag to turn off the syntax highlighter (right now it seems to be tied to the theme setting).
  2. Use a more performant syntax highlighter implementation. Anecdotally, WASM is much slower than the native, and the call between JS and WASM is also extremely expensive. This worsens when you only call the highlighter one line at a time.

For comparison, https://github.com/dandavison/delta uses https://github.com/trishume/syntect and is very fast.

@banga
Copy link
Owner

banga commented May 3, 2021

Hey linjie! Yeah I went down the same path in shikijs/shiki#151, which should speed it up a little (~30% for me). Also see https://github.com/banga/git-split-diffs#performance.

Provide CLI flag to turn off the syntax highlighter (right now it seems to be tied to the theme setting).

You can override the theme setting to disable it, see https://github.com/banga/git-split-diffs#syntax-highlighting

Use a more performant syntax highlighter implementation. Anecdotally, WASM is much slower than the native, and the call between JS and WASM is also extremely expensive. This worsens when you only call the highlighter one line at a time.

I didn't do a lot of research into this, but onigasm claims to be only 2x slower than the native version, which didn't seem like a lot. I also didn't go with syntect etc. because I wanted something that uses the same textmate grammars as vscode so I could use themes that looked consistent with that. https://github.com/shikijs/shiki (which wraps vscode-textmate & onigasm) made this trivially easy, so I didn't spend much more time beyond that. There's also more low hanging fruit there to speed up before trying to cut out WASM – a substantial amount of time is spent in parsing the textmate grammar/theme files.

@pyrocat101
Copy link
Author

I didn't do a lot of research into this, but onigasm claims to be only 2x slower than the native version, which didn't seem like a lot.

As I mentioned here that the call into WASM can be pretty expensive if each of them is only doing a little work. Have you experimented with batching more content for the highlighter?

@banga
Copy link
Owner

banga commented May 3, 2021

Ohh got it. I haven’t, will look into it. It’s a little tricky because buffering will delay the initial render which is when the delay is most noticeable, but it’s probably not that much compared to the wasm overhead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants