It affects disk loading only. So in other words, think of it like this:
1. If the number of max disk threads is 10, and you need to load 4000 items, then it will start loading 10, and then as soon as 1 finishes then it puts another in the list, and then another when the next one finishes, and so forth.
1.a. Assuming that the loading time and processing time are about even, then this is really just as efficient as any other method. However, that is NOT the case, because once something is loaded off disk it needs at least a few ms to convert its format from PNG into a GPU-specific compressed texture format that is prepped for being able to be sent along the bus immediately at any time to the GPU.
1.b. Even assuming that you only had a single-core processor with no hyperthreading or anythinig, case 1 is still somewhat less efficient because your CPU is still able to split things between threads, and your disk IO (which is the biggest bottleneck for any sort of loading operation) is not being fully utilized during the time when there is texture compressing, etc, going on.
2. In the case that we've been using for a while, we used 140 threads at max. So in the case where you need to load 4000 items, the likelihood of your disk IO ever being underutilized is basically zero. The ratio of CPU-processing time to the number of threads to the amount of disk IO at all available on modern hard drives -- even SSDs -- is such that unless you had the fastest SSD possible paired with a 15 year old CPU somehow, then you'd likely not be wasting any disk I/O. Even with theoretical future hardware, as long as CPUs remain equal to or faster than HDD loading speeds when it comes to these sorts of operations, it's perfectly fine. And that's highly likely.
3. However, in the case of the Unity bug, it can randomly tack on an extra 3-10 seconds of CPU "processing" where it does NOTHING. It just sits there, not even spinning cycles or using CPU capacity. What is it doing? I have no idea. It only affects certain systems, and never has affected one of mine. It did affect one of Keith's systems a year or so ago, but does not any longer. Anyway, in this case, Unity is basically "helpfully" simulating your having the worst CPU in the world, paired with whatever your hard drive is. 3-10 seconds to process that texture!? My 800mhz 2001 laptop could have managed better than that.
3.a. In this case, the amount of concurrency matters a lot. If you have 4000 threads to load, and you set a maximum of 4000 threads loading at once, then basically it throws everything at the disk I/O at once. The operating system is going to go "whoa, buddy, you guys are going to have to get in line because you just asked me for a mess-ton of stuff at once." So your disk I/O will be pegged at full capacity, which is what we want. But the OS manages which things get loaded first, and that's fine with us because order doesn't matter. Meanwhile, on the CPU side, while each of these 4000 threads "spaces out pointlessly" for 3-10 seconds, they are all pretty much doing it simultaneously for the most part, or at least close to that, rather than doing it a few at a time. This makes it so that those stupid space-outs happen more on top of one another rather than one after another, in other words.
Anyhow, that's how it helps with that particular issue. How will this affect performance during the rest of the game? Basically it won't. It only affects things like loading graphics and music, and it only has any effect at all when there are more than 140 of them that need to load at once. That almost never happens during the game itself, and if it did happen then that would be a case where you'd get a moment of lag anyway, and if you fall into case #3 above, then it would actually HELP your performance. But in the case of a few images popping in every so often, those are in 2s and 3s, or even a few dozen at once, not 4000 at once, heh.
In terms of negative side effects, there really are none... except that on certain OSes, the number of disk calls are directly tied to the number of threads in a program in general, and the max thread count is set to something like 256. So in those cases, if you exceed 256 threads, you get a crash. Hence my not cranking this up automatically for everyone.
