OptimiseMapGeometryMaterial is sometimes slow

[slipher]

Sometimes the first stage of map load takes an unexpectedly long time. I logged the time spent in the OptimiseMapGeometryMaterial function and on the first run loading Pulse it took 44 seconds.

[VReaperV]

What do you mean on the first run? It always takes ~same amount of time on the same map. Were you running it in debug or didn't have the shaders built?

[slipher]

What do you mean on the first run?

I mean I only tested it once with the timing code. The timing code measured just the runtime of OptimiseMapGeometryMaterial.

But I've noticed it on the loading screen many times already. The BSP loading stage is at the beginning of the loading process and GLSL compiling is at the very end, so it's easy to distinguish. I'm using Visual Studio; RelWithDebInfo plus -DDAEMON_ASSERTS_ENABLED.

[VReaperV]

Weird then... I've never run into this issue.

[slipher]

The bug is intermittent; there is a bimodal distribution - the BSP loading either takes a couple seconds or 40-45 seconds.

I started tracking it down and got as far as determining the time is spent in ProcessStage but then the bug stopped reproducing for the day.

[VReaperV]

Were you using r_materialSeparatePerShader perhaps? There are some linear searches in ProcessStage() and AddStage(), but they're normally not an issue because it only searches over at most a few dozen values. However, that may no longer be the case if that cvar is enabled.

[slipher]

It happened sometimes while using a test script that runs with a clean homepath, so I don't think a stray cvar is to blame.

[VReaperV]

No idea then. It always runs very fast for me.