Slate: how to improve code highlighting example speed?

[istarkov]

Now for 50-100 lines of code Code Highlighting example works very slow.
It takes near second to render on each key press.

I think it's because of marks applied to each character instead of text ranges https://github.com/ianstormtaylor/slate/blob/7128085e9e45c5b35b8e666bac75f595f14167a7/examples/code-highlighting/index.js#L153-L159

I thinks that the way to apply marks on ranges exists,
or code should be split in multiple blocks but not sure.

The question is - how to greatly improve performance of this example?

[SamyPesse]

@istarkov Slate builds range of text from characters list before rendering (each range is rendered by a Leaf).

I'm really interesting in optimizing performance for this use case (slate-prism), here are the potential bottleneck:

• Parsing of code by Prism
• Iterating over the token tree to annotate the characters list
• Rendering the leaf

It will be interesting to measure these different parts and understand which one is causing problems.

But, supporting more than 100/200 lines in a code block with real-time highlighting will always be tricky if we are processing the whole block on each keydown.

Some solutions can be:

• Split code blocks by line (basically have code_block_line blocks inside the code_block blocks) and highlight/process these blocks. The main issue with is for multilines tokens.
• Find a way in the renderDecorations to cache some parts of the code_block and only parse the modified text sections

[istarkov]

Thank you @SamyPesse I also have played with splitting code on line blocks and it works almost fine without so long delays.
There is still an issue with long pressed keys - like backspace, BTW it's not a big issue for me now, and I think I always can debounce or somehow fix this bottleneck in the future.

I like the current editor idea for highlighting as for my current task I already have tokenizer and all I need is just few lines of code to get the nice looking result.

[ianstormtaylor]

Good questions, and I'm definitely open to any changes to improve this. I think there must be a way (more likely multiple smaller ways) to improve the rendering piece alone. And I do think that right now in long, highlighted code blocks, rendering is one of the biggest issues. If anyone dives in with performance analysis, add it here! And we can discuss improvements

[kulakowka]

Today, I was engaged in the creation of the documentation for the Slate in gitbooks. Gitbooks, for example, highlights only short pieces of code (in edit mode). And all of the code highlighted in playback mode. Maybe we should also try this option?

Look at screenshot:

[ianstormtaylor]

Hey, code highlighting should be much faster with all of the changes that have happened since August. I'm going to close this issue, but if anyone notices specific slowness feel free to open a new issue with info