Drivers and Framerate Drops: Why?

Let’s say I have 24 objects, each with their own material. The objects and materials are all the same, but there are an equal number of copies of the material because I need drivers that target different things attached to them so they operate independently. I now have two bones for each material/object. One that I can scale, and another that scales even more based off the first one using a transform constraint. The driver for each material, and this is attached to emission by the way, gets its variable from the scale of the second bone with the transform constraint.

Now when I so much as try to move or scale the first bone (which is a target that each object is damped tracked to), Blender lags like I’m trying to do this all on a 2004 Dell desktop. But only in material preview. Which makes no sense, because location has nothing to do with the drivers and as for scale, why would it be lagging if it’s only one very simple driver calculation? With all 24 objects using only one material and by extension one driver, it still works just fine. I get no framerate drops. Add more drivers though, and no luck.

One important thing to note is that I was troubleshooting this on Discord and cut out the middleman by deleting the bones that control the emission and using custom properties instead. Exact same problem, no performance improvements whenever I would try to change the value of any one of the emissions. This leads me to believe that the target, regardless of what the driver is trying to read or should be reading, such as scale, whether that be a custom property or a container such as an object or a bone, if altered in any way, will be recalculated as the driver looks for updates, and Blender is doing this for every single driver as well even though they’re wholly unrelated/not in the pipeline for the driver’s calculation.

That was a bit of a word salad, but I think it made sense. Blender is looking for any change in the properties of any of its drivers’ targets and if there is one, it runs through the entire host of the .blend file’s drivers before landing on the one that’s actually relevant and changing its value(s). Can anyone confirm that this is an issue with the way Blender treats drivers backend? And is there any good reason as to why it does this? Is there a potential workaround that sacrifices minimal practicality?