Tuesday the next server maintenance pack should roll out to a release channel. For scripters this roll will have llSetRegionPos(), the frame_number parameter for llGetEnv(), and some llSetKeyframedMotion() bug fixes. We’ll find out which channel gets the update Tuesday.
Roll outs are a bit off and the pipeline is a little dry because of last week’s network switch failure. So, I think we will see release channels roll Tuesday instead of Wednesday.
A backend feature has been added. Kelly Linden says it is a % scripts run stat. This tells one what percentage of scripts ran in the last frames as an average. We will eventually see it in the viewer. But, it has the QA pipe to make it through before we see it. Version 3.2.7 made it to the development alpha today. So, % scripts will likely be one or two versions behind that.
This new stat is the average percentage of scripts that ran in the last frames. A 100% average means all scripts are running in every frame.
The details of llSetPrimPramFast(), which is often shortened to llSPPF() in conversation, was discussed some more. It was also discussed in Andrew’s Friday meeting. If I understand correctly, a call to llSPPF() cannot extend across frames. So, if one adds enough work to it that it cannot fit in a frame something has to give. It seems it is server frame rate that takes the hit. The Lindens are looking at how to mitigate that problem.
I suspect most of us think scripts cause lag. But, have you heard that scripts do not lag the server? If so do you believe it? Well… it seems it is true. But, you have to get the nuance of what is being said and connect that with what you see SIM’s doing.
Scripts don’t lag SIM’s. What scripts do, lags SIM’s… If your thinking that is a nuanced spin of the syntax, you’re thinking the same thing I was. But, the point of the nuance is that if you get the point of it, you can make better scripts that do more and lag less.
You can process a list within a script and run hundreds of list processing scripts without lagging the SIM. You could have hundreds of scripts calculating pi and not lag the sim. You could lag script performance for your script and other scripts.
The cost to a SIM comes from rezzing and moving things. Pull the trigger on a Phalanx and throw 600 bullets per second into a region and watch the SIM performance fall off.
Do anything that moves something an avatar can collide with and it is expensive SIM calc-wise as the physics engine updates. Changing linked prim positions and shapes is some of the most lag inducing things an LSL script can do.
You can read Kelly’s comments on this starting about 9:40 in the 1/9/2012 transcript. The link is currently broken. I’ve ask Kelly to look at it.
More or Less Calls
There is a cost in script performance for each call. So, obviously it would seem reasonable to minimize the number of calls and do as much as possible within a call. The trade off in this idea is that fewer calls reduces the servers ability, or number of opportunities, to manage the script load.
So, one often has to do lots of testing in specific conditions to know which choice to make.
Performance and call frequency lead to some interesting problems for the new llSetRegionPos() function. If one places a series of calls and moves lots of prims, it could lag the SIM. The Linden choice is to throttle the function to one use per frame. An immediate repeat of the call would fail.
Soon coming to a release channel near you… In the next (1/17) roll, or possibly the one after, we will get improved List Processing performance in Mono.
The improved functions are; llList2List, llDeleteSubList, llGetListEntryType, llListInsertList, llListFindList, llDumpList2String, llListReplaceList, llVecMag, llVecNorm, llVecDist, llDeleteSubString, llStringLength, llInsertString, and llSubStringIndex.
Kelly says most of these are 2 times faster. The exception is llDumpList2String which changes little. However, the function llList2List is ~100x better and llGetListEntryType is ~150x better. This significally cuts some list function processing time. The function llDeleteSubString is about 20x, llDeleteSubList also about 20x, and llStringLength is ~50x.
If you read my recounts of the scripting meetings, you know there is lots of optimization information available in the meetings. It would be nice to have wiki pages summarizing the optimizations. What we have now is somewhat outdated. Kelly as offered to discuss any new pages the community puts together in the Scripting UG meeting.