Page MenuHomePhorge

Rendering remarkup with many embedded code blocks is very slow
Open, HighPublic


We have the following the article in our phorge wiki: P33

The remarkup parsing of the article takes far too long. It is roughly over 10 seconds. Just try it out here:

  • copy the paste
  • paste it in the comment section of this task
  • see in the network tab the request time for the preview of 14 seconds

I think this can't be normal for such a small text. We should debug what causes this behavior.

Event Timeline

"slow remarkup" often boils down to 1-2 inefficient regexp in a rule somewhere.

I wonder if there's some profiling tools for this already implemented in the codebase.

I'm quite sure the problem is limited on repeated code blocks.

mm, dumping this file in my dev env renders pretty much immediately; that's a good sign that it's the code blocks, because (1) pygments is known to be slow and (2) I don't have it installed.

Update: I've installed pygments (2.15.1), and it took about 3 seconds to render. It takes about 14 seconds here (with pygments 2.3.1).

Probably the best approach is to upgrade Pygments here...

Well, good to know that it is not something in the phorge codebase. Our server has pygmentize 2.14.0 - but the server itself is really not the best, so that could be an explanation. Maybe we could make some remarks about performance and keeping the versions fresh on the diviner page...

And of course do the update on the phorge server 😆

I guess we could also try to cache the individual rendered code-blocks.

(Entire rendered documents are cached, except for previews, so once you're done writing, there's no 14-seconds delay for each page render).

Updated Pygments with pip to 2.17.2 und cut the time in half. So yeah, that's already an improvement.

avivey renamed this task from Parsing for a fairly reasonable sized remarkup text takes too long to Rendering remarkup with many embedded code blocks is very slow.Mar 15 2024, 09:17