Major performance decrease

[ofurtumi]

Not sure how if connected but these last weeks i have almost not been able to use this plugin anymore, if the plugin is active it slows down the current buffer to a snails pace, i also get a similar error when running :TypstWatch as in #63

I don't think this has to do with my system since i have not changed anything these last days, im running on Macos 13.2.1 and using mostly default LazyVim config

[kaarmu]

Hi! I'm truly sorry for the inconvinience. This probably originates from work on #42, more specifically 8a2baba02dd2fa0de42a0392998af03a12ef1994. I suggest you update to latest commit or revert back to before the commit above.

Though, I don't understand how the changes affected your performance this much.

[kaarmu]

Please also check the updates I wrote about in #63.

[ofurtumi]

Thanks for the quick response, i'll try that now

[ofurtumi]

Update: reverting to e4d0721 seems to fix the problem, everything after that gives me this issue.

[kaarmu]

Really... That's interesting. Then it seems that the math conceal feature is causing your problem.

Sadly, I'm unavailable to test this on my side until next week. If you want to help confirm the issue you can try commenting out syntax/typst.vim#L343 while being on main.

Otherwise I will look into it as soon as I can.

[ofurtumi]

This worked, commenting out line 343 does the trick

[PhyX-Meow]

@ofurtumi Do you use cursorcolumn option of vim? It would cause a huge performance decrease when using with conceal feature. I usually disable it when editing tex and typst files.

[ofurtumi]

@PhyX-Meow nope, i don't use cursorcolumn

[yangwenbo99]

@ofurtumi Keeping line 343 but commenting out the rule for typstMarkupItalic (around line 290) seems also fix (or at least reduce) the issue on my computer. Could you try it on your side?

[ofurtumi]

@yangwenbo99 reverting on line 343 and commenting the lines for typstMarkupItalic (i commented out 290-292) seems to reduce the problem like you said but it is definitely still there.

I went a little deeper into line 343 and instead of commenting it out, check which parts of typst-symbols.vim are causing the biggest issue. Commenting out the for loop referencing the first array gets rid of the problem almost completely however the other loops are not noticable by themselves. I think this is because their arrays combined include less than a quarter number of items than in the first array.

[kaarmu]

Hmm. Looking through vimtex code it seems like they do something similar as @yangwenbo99's loops (and I don't see how they couldn't) for concealment. So it feels like something else is at play, I mean it's only 1000 entries or so combined in our lists.

So, I'm trying out vimtex's approach of calling autoload function. For some reason I cannot reproduce this problem so I'd love if you, @ofurtumi, could test if it helps. The changes are in the autoload-fun branch.

[ofurtumi]

Tried it, i think @yangwenbo99's loop is better, using the autoload-fun branch i'm even slower can barely move around, is there any info, log or something i can add to help?

[yangwenbo99]

@ofurtumi How is vimtex on your computer? Do you encounter similar slow down? If not, I guess there might be some problems with the look-ahead and look-behind operations introduced in my code and other regexes in highlights. The highligh parsing of typst is more complex than latex's, as latex always uses forward slash \ for symbols.

[kaarmu]

Using https://github.com/vim-scripts/TIMEIT I get that call typst#syntax#symbols#all_symbols() from autoload-fun branch takes 0.4 ms on my system.

[yangwenbo99]

My guess is that most computation was spent on regex matching, so loading is probably not the most important issue.

[ofurtumi]

@yangwenbo99 i don't have a complete latex setup right now but i tried editing a couple of latex files after installing vimtex and i get some slowing down, nothing terrible. It is there but i think i would not really notice it if i were not looking for it.

[PhyX-Meow]

Well, I met the same issue, rolling screen gets super slow when I'm editing a over 300 lines typst file. Commenting out syntax/typst.vim#L353 (L343 previously) solve the issue.

[PhyX-Meow]

I'm using vimtex too, it works fine and smoothly with files with 1k lines. See https://github.com/lervag/vimtex/blob/7785ecd75b9a71a22ac33a8250e3bf4eaca6b439/autoload/vimtex/syntax/core.vim

[kaarmu]

Sorry for the inactivity, quite busy weeks now. Could someone provide an example file because I can't seem to recreate the problem :/

[PhyX-Meow]

test-file.zip Here is the file I met the problem, just open the file with typst.vim plugin on and conceallevel=2. Then hold j or <ctrl-d> or something similar. I'm afraid you may be not able to compile the file because I used lemmify v0.2.0 which I manually clone from its git repo.

[jiandwei]

Well, I met the same issue, rolling screen gets super slow when I'm editing a over 300 lines typst file. Commenting out syntax/typst.vim#L353 (L343 previously) solve the issue.

Do you use the third config such as LazyVim? I ever use itm and it is slow, but when I make a configuration by myself, it works well.

[kaarmu]

Okay, nice. Thank you @PhyX-Meow. It is not terrible for me but I can definitely see performance taking a hit.

@jiandwei, I use both normal vim and neovim. My vim config is very bare bones and my neovim is a stripped lazyvim config. That could be a reason why it's not impacting me as much.

[PhyX-Meow]

Well, I met the same issue, rolling screen gets super slow when I'm editing a over 300 lines typst file. Commenting out syntax/typst.vim#L353 (L343 previously) solve the issue.

Do you use the third config such as LazyVim? I ever use itm and it is slow, but when I make a configuration by myself, it works well.

Unfortunately, no. You can review my vimrc if you wish at https://github.com/PhyX-Meow/dotfiles/blob/main/.vimrc

[kaarmu]

I just now realized, stupidly late, that typst-symbols.vim (syntax rules for concealment) also affected people not using concealment... In e72561f I added an option g:typst_conceal_math to enable concealing math symbol, default set to false. This should at least remove the problem for those not using concealment.

In steps towards fixing the problem completely, I started improving the regexes in 82a8a86, which helped somewhat for me, but the issues are still there.

[yangwenbo99]

On my computer, it seems that 82a8a86 fixed the issues with math, bold, and italic. Still, I have been experienced problems with slow matching with comments.

To reproduce the issue, just use a block comment to comment out line 573 to line 675 in @PhyX-Meow's example file. The scrolling of comments are even slower than math, bold, and italic, which is very weird.

[yangwenbo99]

On my computer, it seems that 82a8a86 fixed the issues with math, bold, and italic. Still, I have been experienced problems with slow matching with comments.

To reproduce the issue, just use a block comment to comment out line 573 to line 675 in @PhyX-Meow's example file. The scrolling of comments are even slower than math, bold, and italic, which is very weird.

It appears that using the group match in c.vim resolves the issue:

syntax region typstCommentBlock matchgroup=typstCommentStart start="/\*" end="\*/"
    \ contains=typstCommentTodo,@Spell fold extend
syntax region  typstCommentLine start="//" skip="\\$" end="$" keepend
    \ contains=typstCommentTodo,@Spell
highlight default link typstCommentStart            Comment

[kaarmu]

I think we are getting somewhere! After some time sitting with this I have now played around with different syntax rules for the math symbols. Turns out less is more! I've been more satisfied with having less correct concealment (it conceals when it shouldn't) but it's faster.

It is now getting to the point where I need to improve regexes for other parts of the syntax, e.g. Italic/Bold is up next. The drawback is that Gammaa will conceal to Γa and so forth. This can probably be fixed but I think it's worth asking if this is sufficient for the time being. If that's the case then I suggest we close this issue and open new for subsequent, more specific problems, e.g. Gammaa.

You can try out the new syntax in performant-conceal branch and please comment any thoughts or opinions!