I have seen a growing number of people in Second Life lately claiming that excessive script memory use does not create lag.
I understand the argument. Theoretically, when script memory use exceeds a sim's allotted 300MB of memory (I've also heard 100MB, not sure which is the case), scripts simply cease to function, going into a queue until it's their turn to get some of the sim's limited resources. A step LL took deliberately to reduce sim lag.
It makes sense, and yet experience tells me it's not entirely true.
Just today I was at the Island of Milk & Cream, a sim I did the majority of the building and design for, when the lag spiked terribly. With 10 people in the sim, at one point four of whom were using around 20-26MB of script memory. One of them quickly left but three remained. The avatars in range of my script memory HUD were totaling 120MB of script memory, in addition to whatever the various builds in the sim take up and the avatars not close enough for me to see.
As the worst offenders dwindled to only one. the sim performance improved substantially. At the moment there are still 8 people in the sim totally only 38MB and the lag is pretty much gone.
Another sim I frequent, Doomed Ship, regularly has 10-20 people or more and yet never has lag as bad as Milk&Cream regularly experiences. Neither sim is a Homestead, they're both full sims. The difference is that Doomed Ship does not allow individual avatars to exceed 7MB of script use and runs a campaign to encourage as little individual script impact by avatars as possible. They're quite friendly and helpful about it with staff members willing to take the time to actually sit down with visitors and help them reduce scripts without losing their favourite features.
Admittedly, this is all based off my experiences, not hard technical knowledge of how script memory impacts sim performance. However I work closely with a number of SL's top scripting talent and they all agree that script memory use does have an effect.
When Linden Lab first introduced the feature to see script memory use among avatars many people worried it would turn into some sort of witch hunt. In some places in SL maybe it did, but I never experienced it. Most places I have seen which even have public "script use boards" displaying avatar memory use still have no actual rules against excessive script use, but encourage people to understand that such excessive script use is a primary cause of lag.
I think that is a good first step that should see wider use. Rather than immediately clamping down, popular areas should merely point out avatar script use and explain how it impacts the performance of the sim for everyone. Explaining how to avoid excessive script use while still enjoying the range of features people are accustomed to (lower script memory use does not mean sacrificing features, many scripted items in SL are simply scripted poorly and there are better scripted alternatives).
LL should also make it easier for the average SL resident to check their own script memory use and what attachments contribute the most to their impact on sim performance.
I'd go so far as to say LL should make some of the better shopping habits a part of their own suggestions to new residents.
1. Avoid no-mod scripted items.
2. Look for script memory use to be listed on vendors. If script memory use is not listed, ask the creator how much memory the attachment (and any accompanying HUDs) uses.
3. Remove scripted items that you do not actually use, such as combat or role-play HUDs in areas where they serve no purpose. Or hidden attachments that you're not currently using.
4. Remove unused scripts from attachments. If you have a favourite gun you wear on your intergalactic bounty hunter avatar, but you don't actually use it's scripted features it's just for looks, make a copy and remove the scripts! Have some heavy armour filled with colour change scripts you never use? Remove those scripts! Resizable hair? After it's fitted, make a copy and remove the scripts from the copy you wear.
4. Try and keep your overall script memory use under 2,000kb. Most places generally suggest 5,000kb but you really should be able to have all the features you enjoy and stay well under 2,000kb. Aiming for 2,000kb and lower (I'm usually around 400kb-500kb and my avatar is heavily scripted with features) will put more demand on content creators for efficiently scripted attachments and HUDs.
Content creators themselves should remember to try and make script efficiency a feature. Advertise how little script memory your attachments eat up. Work towards reducing the number of scripts in your creations whenever possible.
Linden Lab should take this a step further by making script memory a part of marketplace listings just like perms and prim count.
The onus is on LL and content creators if we want people to reduce their script use. The average user just knows that they want their features, and reducing script use by sacrificing those features is not what they want. However, once low-memory alternatives are available, it becomes much easier for them. There's really no reason why having a well scripted avatar shouldn't be that easy.
Script memory use doesn't directly affect sim performance until it starts reaching the sim's RAM limit. Then, the operating system will start storing temporary memory on a section of the hard drives.
ReplyDeleteHD access is far slower than RAM access, so this further slows things down. If RAM runs completely out, then all paging is done on the hard drive.
However, this is only when RAM usage is excessive. The other factor affecting sim performance is what the scripts are doing. In general, the more a script is doing at once, the more CPU resources it'll use.
The simulator is designed to give scripts minimal CPU priority, meaning that scripts will start slowing down when other things the simulator is doing are eating up a lot of CPU time, such as heavy physics processing.
In theory, scripts should not negatively impact sim performance, but in reality they will. Any script functions that utilize networking (email, HTTP) or have a visible effect (primitive params, particles) will need to access code outside of the script's execution engine, and therefor can negatively impact simulator performance when done in excess. If scripts are firing more frequently (such as ZHAO animation overriders or anything running on a short timer), then they will have a greater impact as well.
So, in short: if RAM usage is low, then scripts affect performance more with what they do than how heavy they are. But once the simulator starts running low on RAM, then the script memory becomes a problem.
There's a reason that creators have been slow to provide script memory data, and that's because there's been no way to do it accurately if any of those scripts were Mono-compiled. That's slated to change, and there's already one step toward accurate reporting.
ReplyDeleteThe underlying problem is that it's expensive to measure the amount of memory actually used by a Mono-compiled script, so that is *not* what is exposed. Rather, current external script memory measurements (such as whatever Doomed Ship is using) can only assume the worst-case 64KB for every Mono script, although the actual usage is frequently as low as 4KB. So, when your HUD saw 120MB used by avatars nearby, the real number may have been as low as 7.5... or it may have actually been 120. There's simply no way for anybody to guess whether one user is really using more memory than another who's reported to be using over ten times as much!
At least it's now possible for scripters to know the peak memory usage of their own scripts, thanks to llScriptProfiler() and related new LSL functions. This measures memory use by the profiled script (albeit very, *very* slowly).
Currently, however, one would have to take the scripter's word for that number, so pretty much nobody is posting it on products. What's coming soon, however, is the ability to set a memory usage ceiling for scripts. At that point, it will be viable to expose those ceiling settings to external measurement so both consumers and venues can have accurate information for their decisions.