Babbage just said “As of 10 minutes ago, Mono scripts now rez in 100 us instead of 15 ms on my development sim. I will try to get the fix deployed as soon as possible.” This is a really really good thing, as this bug is likely one of the major culprits to why SL has seemed so darn jerky and laggy since shortly after Mono was deployed (29 August 2008). The problem has been tracked at http://jira.secondlife.com/browse/SVC-3895 if you are interested in the gory details.
A few people have asked why this is a big deal and what impact will the fix make. Of course, at this point, it remains to be seen, but look the difference between 100 microseconds and 15 milliseconds… with the bug in place, each Mono script takes an extra 14.9 milliseconds to rez. Doesn’t seem like much, huh? After all, there are about 67 of those 14.9ms in ever second. But one fancy hair build with a built-in resizer might have (lets make it easy) 100 scripts, so just rezzing that one avatar’s hair would take an extra nearly 1.5 seconds of time. But wait, it gets worse! The sim, is (of course) doing lots of other stuff that competes both directly and indirectly with the time it can spend rezzing objects… like physics (so your avatar can move around), actually running scripts (so your AO works), as well as more prosaic stuff like sending textures and object structure to your viewer. Adding to the problem is that SL rezzes objects transactionally, so that either the whole object rezzes or none of it does – this means that not only does rezzing compete with all the other stuff, but that once it starts rezzing that trendy hair object, it wont do anything else until it is done – 1.5 extra seconds of absolutely nothing in the sim!
There are probably secondary effects too: TP failures, probably chat lag and object (maybe money) transaction lag and/or misdelivery. It isn’t inconceivable that long service delays mess up UDP transport expectations resulting in extra network traffic for retransmission requests.
Anyway. So hopefully Babbage’s fix will get fast-tracked for deployment – it’ll be nice to see how much of the rather counterproductive hysteria over Openspace resource use (Coming to a head on October 28, 2008), and various other performance problems leading to near-term plans for imposing script limits will turn out to be rendered moot by this fix. Probably wont change anything, but we can dream!