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

Don't call setTheme if _theme hasn't changed #151

Merged
merged 1 commit into from
Apr 30, 2021
Merged

Conversation

banga
Copy link
Contributor

@banga banga commented Apr 23, 2021

setTheme can be an expensive operation because it parses the raw theme
every time it's called:
https://github.com/microsoft/vscode-textmate/blob/9e3c5941668cbfcee5095eaec0e58090fda8f316/src/main.ts#L93-L95

In https://github.com/banga/git-split-diffs/, I invoke
codeToThemedTokens many times, one line at a time, so the cost of
setTheme adds up. In my local profiling, this was taking about 25% of
the time spent in codeToThemedTokens. I realize this is probably not
the intended way to use this function, but there isn't an easy
alternative for syntax highlighting individual lines in a diff.

Before
image

After
image

`setTheme` can be an expensive operation because it parses the raw theme
every time it's called:
https://github.com/microsoft/vscode-textmate/blob/9e3c5941668cbfcee5095eaec0e58090fda8f316/src/main.ts#L93-L95

In https://github.com/banga/git-split-diffs/, I invoke
`codeToThemedTokens` many times, one line at a time, so the cost of
`setTheme` adds up. In my local profiling, this was taking about 25% of
the time spent in `codeToThemedTokens`. I realize this is probably not
the intended way to use this function, but there isn't an easy
alternative for syntax highlighting individual lines in a diff.
@banga
Copy link
Contributor Author

banga commented Apr 29, 2021

cc @octref in case you haven’t seen this PR. Thanks!

Copy link
Collaborator

@octref octref left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution! The only thing I'm not 100% happy about is we are doing object comparsion, not name comparison, so the code here is a bit dirty. I'll open another issue to make name required in IShikiTheme and change the comparison here.

@octref octref merged commit 2d41061 into shikijs:master Apr 30, 2021
@banga
Copy link
Contributor Author

banga commented Apr 30, 2021

Makes sense, thank you!

@octref
Copy link
Collaborator

octref commented May 2, 2021

Hey @banga, I just saw your repo on HN frontpage, congrats!
I'm wondering if I can mention it in "related projects" section. Additionally, do you have any thoughts on making a terminal renderer for shiki? I have had this thought but haven't given it a try. Would love to know if you have run into any bumps there.

@banga
Copy link
Contributor Author

banga commented May 3, 2021

Thanks and thank you for making this project!

I'm wondering if I can mention it in "related projects" section.

Yes of course!

Additionally, do you have any thoughts on making a terminal renderer for shiki? I have had this thought but haven't given it a try. Would love to know if you have run into any bumps there.

Yeah that sounds useful. The initial implementation was actually really easy. I used chalk which already supports hex colors and converts them to appropriate ANSI sequences for the current terminal.

I eventually had to do more work for supporting alpha in colors (so I could e.g. highlight inline changes without overwriting the underlying syntax highlighting), so I implemented https://github.com/banga/git-split-diffs/blob/main/src/SpannedString.ts. It felt like I was sort of reinventing html, but I needed something tailored to my use-case of highlighting spans in a line, one line at a time, and then flattening it into styled segments.

Slightly unrelated, but one thing I'm invested in for my project is speeding up startup time – we currently spend a bunch of time in parsing the grammars and themes to in-memory structures. I know very little about the internals of vscode-textmate, but it seems that there might be a way to cache this parsed version on disk and quickly load that in instead? That would be helpful in enabling more CLI apps to use this project, since developers tend to be really sensitive to perf issues in those.

@octref
Copy link
Collaborator

octref commented Jun 24, 2021

cache this parsed version on disk and quickly load that in instead

@banga I just came across this issue again. I currently don't have time to look into this yet. Would be great if that could happen.

@banga
Copy link
Contributor Author

banga commented Jul 31, 2021

cache this parsed version on disk and quickly load that in instead

@banga I just came across this issue again. I currently don't have time to look into this yet. Would be great if that could happen.

I tried this today, but it was actually slightly (~6%) slower in my tests. This is what I tried: microsoft/vscode-textmate@main...banga:main.

Separately, I noticed that after updating to v0.9.5, the startup time got much slower. This seems to be because we now default to loading all BUNDLED_LANGUAGES if you don't specify a non-empty langs option. Perhaps some people are running into this?

@octref
Copy link
Collaborator

octref commented Aug 14, 2021

Separately, I noticed that after updating to v0.9.5, the startup time got much slower. This seems to be because we now default to loading all BUNDLED_LANGUAGES if you don't specify a non-empty langs option. Perhaps some people are running into this?

I just opened #200.

I tried this today, but it was actually slightly (~6%) slower in my tests. This is what I tried: microsoft/[email protected]:main.

To avoid losing contexts, do you mind opening a new issue so we can track this? Plan to fix this, but needs more digging into it.

banga added a commit to banga/shikiji that referenced this pull request Dec 28, 2023
banga added a commit to banga/shikiji that referenced this pull request Dec 28, 2023
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

Successfully merging this pull request may close these issues.

2 participants