Build time with syntax highlighting in 0.22.0 is 50x slower than in 0.21.0

[ziggi]

Bug Report

Environment

Zola version: 0.22.0
OS: macOS 15.7.3

Expected Behavior

Enabling syntax highlighting should not significantly degrade build performance compared to previous versions.

Current Behavior

Build times:

• 0.21.0 without syntax highlighting: 120ms
• 0.21.0 with syntax highlighting: 320ms
• 0.22.0 without syntax highlighting: 110ms
• 0.22.0 with syntax highlighting: 6500ms (6.5s)

config.toml for 0.21.0:

[markdown]
highlight_code = true
highlight_theme = "OneHalfLight"
extra_syntaxes_and_themes = ["syntaxes"]
insert_anchor_links = "right"
external_links_no_follow = true

config.toml for 0.22.0:

[markdown.highlighting]
theme = "github-dark"

Build time depends on the number of code blocks. Some languages are faster, others slower: js and ts produce the same results, but coffee is about 4.5x faster. php is also slow. Even though c is about 5x faster than ts, overall the build is still slow - for example, 150 c blocks result in a build time of around 1100 ms.

Step to reproduce

Add this code (or any other) to your markdown file with ts syntax highlighting, copy and paste it as many times as needed, and measure the build time.

const createResultElement = (result: FuseResult<SearchIndexItem>) => {
  const el = document.createElement('a');
  el.classList.add('search-results__item');
  el.href = result.item.url;

  const titleEl = document.createElement('div');
  titleEl.classList.add('search-item__title');
  titleEl.innerHTML = result.item.title;

  const textEl = document.createElement('div');
  textEl.classList.add('search-item__text');
  textEl.innerHTML = result.item.body.slice(0, 100);

  el.insertAdjacentElement('afterbegin', textEl);
  el.insertAdjacentElement('afterbegin', titleEl);

  return el;
}

[Keats]

This is weird, the benchmark for highlighting for giallo is in the same ballpark as syntect: 350ms to highlight the full jquery file (9200 lines)
Moving to the giallo repo to investigate

[Keats]

So a 300L of that TS in giallo:

highlight sample.ts     time:   [42.281 ms 42.649 ms 43.141 ms]
                        change: [−1.4533% −0.4747% +0.9965%] (p = 0.40 > 0.05)
                        No change in performance detected.

and in syntect using the JS syntax since TS is not part of the default

highlight/"slow.js"     time:   [7.6879 ms 7.7201 ms 7.7461 ms]                               
                        change: [-0.0811% +0.3433% +0.7749%] (p = 0.15 > 0.05)

and syntect highlights the jquery file in 150ms.

I'll need to profile on the small benchmark but I did do it on the jquery file before releasing and it came out to the vscode approach doing a lot more regex call in practice to highlight something. About 80% of the time was spent in onig.

The shiki playground with onig does render the sample.ts file in 16ms so i'm probably doing something wrong somewhere though. It can't be almost 3x slower than wasm?!

[ziggi]

On my side single jquery file in zola builds in ~750ms, but:

• 100 blocks with just const builds in 918ms.
• 100 blocks with const x builds in 1800ms.
• 100 blocks with const x = 1; builds in 2700ms.

[Keats]

That one is a known issue, cache is per highlighted text so you pay for the regex compilation each time. Easier for vscode since it's single threaded. I have an idea to share the compiled regexes though but it will be much easier if we can use fancy-regex rather than onig (#21)

[Keats]

#41 solves the multiple highlight issue, you will pay a few ms for the first codeblock to highlight but the next ones should be in the microsecond range.

Can you try getzola/zola#3067 that contains that change?

[ziggi]

On this branch the build takes 1.8s

[ziggi]

This was on a debug build, on release the build takes 675 ms. Much faster but twice as slow as in 0.21.0.

[Keats]

giallo is about 2x slower than syntect for the jquery file so that tracks. When I checked for the jquery file, giallo does almost 2x the number of regex calls. I don't think there's any obvious optimizations missing anymore in giallo but I would love to be proven wrong.

[nicoburns]

Not sure that it will help (as always, you'd have to measure), but you could try thread-local regexes to eliminate the Mutex.

[Keats]

I would need to measure but I guessed the contention on the Mutex wouldn't be huge since it's on a specific regex set of a grammar and executing the regex is pretty fast.

[radekmie]

I can confirm that on my blog, with 161 code blocks (mostly diff and ts) across 61 pages, it also increased significantly in 0.22.0 and got better in 0.22.1:

• 159ms on 0.21.0 (highlight_theme = 'css')
• 4.9s on 0.22.0 (style = 'class' and theme = 'github-light')
• 523ms on 0.22.1 (same config as 0.22.0)

Let me know if there's anything I could measure or try out to help.

[Keats]

Honestly at this point it would be good to have other pairs of eyes look at the code. I'm fairly sure I'm not missing critical optimizations but giallo is about 2x slower than syntect. IMO it's due to giallo doing a lot more regex calls than syntect due to the engine, I've tried to implement the same optimization that syntect does (https://github.com/trishume/syntect/blob/master/src/parsing/parser.rs#L83) but it was slower in giallo than using regset.