WebGLLights: Inefficient string concatenations

https://github.com/mrdoob/three.js/blob/8c6d24b0876f0f7d23aa60be55d6570f4ddb4d6b/src/renderers/webgl/WebGLLights.js#L319

Related PR: https://github.com/mrdoob/three.js/pull/14568

This line is executed 60 times per second thus produces garbage as seen on Chrome’s Allocation Profiler:

The hash value of WebGLLights should be an object instead of concatanated string:

hash: {
stateID: -1,
directionalLength: -1,
pointLength: -1,
spotLength: -1,
rectAreaLength: -1,
hemiLength: -1,
shadowsLength: -1
}

In the WebGLRenderer.js the values should be compared as:

} else if ( materialProperties.lightsHash.stateID !== lights.state.hash.stateID ||
        materialProperties.lightsHash.directionalLength !== lights.state.hash.directionalLength ||
	materialProperties.lightsHash.pointLength !== lights.state.hash.pointLength ||
        materialProperties.lightsHash.spotLength !== lights.state.hash.spotLength ||
	materialProperties.lightsHash.rectAreaLength !== lights.state.hash.rectAreaLength ||
	materialProperties.lightsHash.hemiLength !== lights.state.hash.hemiLength ||
	materialProperties.lightsHash.shadowsLength !== lights.state.hash.shadowsLength ) {

Since JS assigns objects by reference materialProperties.lightsHash should be updated like this to avoid potenial bugs caused by string to object switch:

materialProperties.lightsHash.stateID = lights.state.hash.stateID;
materialProperties.lightsHash.directionalLength = lights.state.hash.directionalLength;
materialProperties.lightsHash.pointLength = lights.state.hash.pointLength;
materialProperties.lightsHash.spotLength = lights.state.hash.spotLength;
materialProperties.lightsHash.rectAreaLength = lights.state.hash.rectAreaLength;
materialProperties.lightsHash.hemiLength = lights.state.hash.hemiLength;
materialProperties.lightsHash.shadowsLength = lights.state.hash.shadowsLength;

instead of:

materialProperties.lightsHash = lights.state.hash

Any ideas/opinions?

[oguzeroglu]

@Usnul

You’re absolutely right abot the hash concept here but this issue is about reducing the GC activity by avoiding creation of new objects in the render loop. In the solution proposed by me the objects are created only once but their properties (which are all integer values, no strings here) are changed inside the loop so it should be quite cheap considering the memory usage. If I understood your proposal correctly a new String object would be created inside the render loop anyway when we hash couple of integers together (AFAIK you cannot reuse Strings since they are immutable objects). So your proposal is exactly what I suggest avoiding in this issue.

I’m not saying it’s not a good idea or anything, it is just against what this issue proposes that’s all 😃

[Usnul]

Well, to avoid guesses as to my position. I believe a 32bit integer is sufficient in a lot of cases, and beyond that I would guess a decent 128 bit non-cryptographic hashing like metro-hash is a good solution.

A note about 32bits - integers in JS are 32 bit explicitly, whenever you decide to use any bit twiddling operations - a number gets truncated to a 32bit int.