Weird performance drop while changing volumes count in runtime

[REDSIM]

What the bug does

If you disable a regular Light Volume in runtime, and then enable - it degrades the performance. Fortunately, seems like this bug has no cumulative effect and only drops the performance only once on the certain amount.
What is even more weird - you can fix the bug in runtime by disabling and enabling a Point Light Volume in the scene.

How to reproduce the bug

1. Go to the Example.unity scene, provided with the package
2. Enable the Overdrawing Benchmark game object, in hierarchy which is actually 100 quads with a transparent LV material, to cause a massive overdrawing and profile the performance in play mode.
3. Add a Point Light Volume to the scene and place it anywhere, it doesn't matter. (There are no Point Light Volumes on the scene by default)
4. Go to play mode and enable the Profiler in GPU mode.
5. Now disable and enable pretty much any regular light volume.
6. You'll see a really noticeable performance drop in profiler. Doing it more times and with other volumes too doesn't drops performance more.
7. Now you can fix this bug in runtime by enabling and disabling the Point Light Volume in the scene.

Note

Doing this operations fast and chaotically, after some time will make it impossible to fix the performance with the Point Light Volume toggle for some reason.

There's also a video I recorded that demonstrates the bug: https://youtu.be/rc_qAe4PRUI

Where it is reproducible

I tried uploading this world in VRChat with some local toggles for the volumes, and based on the FPS changes, it still exists in VRChat, not only in editor.
Have no idea about the Android builds, didn't check them.

Some research I already did

I simplified the Light Volumes Manager udon script to make it possible to directly change the float _UdonLightVolumeCount and float _UdonPointLightVolumeCount global shader variables. And looks like just changing this values is enough to reproduce this bug.
So, changing _UdonLightVolumeCount value drops the performance and changing _UdonPointLightVolumeCount fixes it back. So, probably it's not the problem related to Udon scripts, might be the problem in Light Volumes shader code itself, which makes it even more weird.

When the issue appeared

I noticed this bug in early LV development stage, so most probably it was always since the first (or almost first) Light Volumes prototypes.

[REDSIM]

Some other notes:

• On some PCs it's reproducible, on some - not. Don't know if it's related to a GPU, or the system, or the other factors.
• Thankfully to @owlboy, I minimized the FPS drop by doing some weird thing: For every for loop, I made the main comparison static, limited by a max possible count number. And added an extra if branch inside to break from the loop. Looks like it improved the performance degradation significantly, but still didn't fix it completely.

How it works now for almost every loop:

#define VRCLV_MAX_VOLUMES_COUNT 32

[loop] for (uint id = 0; id < VRCLV_MAX_VOLUMES_COUNT; id++) {
        [branch] if (id >= volumesCount) break;
       // ... code here ...
}

[owlboy]

Just a note for anyone exploring this issue:
#64 Removed the "workaround" that was implemented. Probably for good reason. So this issue is back where it started.