Massive performance penalty using non semantic debug info

[Axel-Reactor]

We are compiling pretty large GLSL compute shaders (~22k lines). Usually glslang takes a little slow but reasonable ~600ms to do this on my Zen5 desktop machine, but when enabling non semantic debug info this shoots up to >10s.

[arcady-lunarg]

If you could attach a sample shader, that would make it much easier for us to reproduce the issue. It might also be helpful to specify which platform you're running this on. If you want to do some profiling yourself to try to see where it's spending its time, that would be even better.

[Novum]

Here is one of the shaders (I had to obfuscate the symbols). Not the worst case, but still clearly shows the problem:

$ time glslangValidator -V --target-env vulkan1.4 test.comp 
test.comp

real	0m0.199s
user	0m0.152s
sys	0m0.047s

$ time glslangValidator -gVS -V --target-env vulkan1.4 test.comp 
test.comp

real	0m2.284s
user	0m2.226s
sys	0m0.049s

test.zip

[arcady-lunarg]

Thanks, I can reproduce it with the shader you gave. Running some profiles, I think I understand what's happening. Because nonsemantic instructions only have Id operands, and because line tracking debuginfo is emitted pretty much for each line in your shader, it needs to create an OpConstant instruction for every line number. However, the routine that creates these constant instructions first checks whether one already exists for the requested type and constant, and does so using a simple linear search. This results in a quadratic slowdown that basically depends on the number of unique constants created.

[Axel-Reactor]

Hey would you be interested in a PR to fix this? If you can point me at that linear search I can give it a go

[arcady-lunarg]

@Axel-Reactor the linear search is in the findScalarConstant method in SPIRV/SpvBuilder.cpp and is really a result of the fact that the existing constants are stored in a vector in groupedConstants[type] which would probably need to be an unordered_map instead. A PR would certainly be welcome.