WebGLShaderCache poor performance

Describe the bug

The WebGLShaderCache uses full vertex/fragment shader source code as keys in a Map<string, WebGLShaderStage> and performs several lookups per frame, causing noticeably poor performance.

To Reproduce

1. Create a RawShaderMaterial subclass with a non-trivial vertex and/or fragment shader (a few hundred lines of GLSL)
2. Render 10k object instances using this material
3. Record a performance trace in Chrome dev tools
4. Observe the time spent in WebGLShaderCache#_getShaderStage()

Expected behavior

• Avoid double-lookups in the common path: instead of .has() followed by .get(), use a single .get() when possible
• Allow materials to specify their own vertexShaderKey and fragmentShaderKey strings that will be used instead of the full shader source code

I have made both of these changes in a patched version of three.js we use in Foxglove Studio (see https://github.com/foxglove/studio/blob/main/patches/three.patch). I’d be happy to turn this into a PR for three.js if this seems like the right approach.

Platform:

• Device: All
• OS: All
• Browser: All
• Three.js version: dev

[jhurliman]

Another option could be generating hashes of the shader sources and storing them as material properties that are used for lookups instead of the full source. I think this would be possible without an API change.

[gero3]

@Mugen87

There are several examples with onBeforeCompile which set the vertex shader just before compilation, so it seems the paradigm of setting shaders after creation is something that has more impact than I first envisioned.

Examples that use onBeforeCompile to change the shader text (this is not a complete list)

• webgl_gpgpu_birds_gltf.html
• webgl_materials_modified.html