"dormant" scripts aren't as dormant as you think

This is a great thread - very useful info! Thanks for sharing the results of your testing, Lex - and to everyone else for brainstorming this topic. I will certainly be more careful about leaving supposedly inactive scripts in my objects.

One thing I just can't get over after reading this thread - do people really walk around with hundreds of scripts in their Avs?! Craziness. I understand the desire to look good and have a unique Av, but it seems that common sense would kick in and folks would realize that they are impacting the performance of the entire Sim.

I have one of those super-fancy dragon Avs. It is an amazing piece of work, but as soon as I put it on I realized that there was no way I could wear it all the time. It is just too complicated. I still wear it on an occasion, tho - usually while goofing around friends. hehe

I hope the info that has been presented here will be spread throughout the building community and we can all be a little more careful when we create complicated objects and Avs. Some more useful diagnostic tools from LL would be very nice, too. I really wish there was an easy way for the average Av to see the effects that individual objects/scripts have on Sim Performance.

Also - Thanks for the tip about using an Empty Sim to check out the performance impact of an Av. I am floating in the middle of nowhere right now - trying on 20 differenct Avs and duplicating objects like crazy. Very interesting.

Sometimes it's in the range of thousands, but usually that's only when they're wearing orbiters. The worst offenders are those who are wearing detailed wings and other such items with multiple "frames" that are cycled using transparency changes. The only way to get all of the prims to appear to change at once is to put a script in every prim and use link messages, and that can often mean hundreds of scripts. Logic says that those scripts shouldn't hurt the sim since they're doing absolutely nothing most of the time... but unfortunately, that's not true.

This is a bug. Just bug reported it.

Though, most likely, as was suggested above .. we're waiting for mono.

I'd like to know if this will be fixed in mono though. Otherwise, how I do scripting should probably change..

I was suprized when I found out my AV had a linkmessage script in every prim to change alpha. I've done some teasting and for compaison my "Weppon scanner" script which does a llSensor repeate adds about 1ms for every 10 to 30 copys. I need to do the test again due to sim not being empty.




FYI:
Actualy I have a device driver that works under windows 2000 and XP that lets me set the permission map so that I can do IN and OUT directly to the parrallel port. I do have to disable the Paraport.sys driver though to prevent it from interfering. I know it was a knuge, but it's a legacy dos program and the new windows version is not done yet.

So, someone mentioned this result to me in chat and I was skeptical. However, I went and ran my own version of the test.

Conditions: Empty sim (only me and the water), no attachments, default 100% flat terrain.

Initial sim stats: total-frame-time:.1ms, script-time:0ms

Test 1: Rezzed 128 empty cubes.
Result: No effect whatever.

Test 2: Rezzed 128 cubes each containing 1 script with no events
Result: total-frame-time:.3ms, script-time:.2ms

Test 3: Rezzed 1 cube containing 128 copies of the same script as above
Result: total-frame-time:.3ms, script-time:.2ms

So, that backs-up Lex's findings.
We can say from that, that an empty script adds approximately 0.0016ms (1.6us) to the script time.
While that isn't completely insignificant, it is pretty low.

For comparison, script run-times taken by a few devices I have around:
(as indicated by the Estate Script tool)

Apez.iServ -0.018ms
JEVN server - 0.026ms
Apez.iVend - 0.023ms
InfoNet R5 notebook - 0.046ms
Mauriac Large message board - .119ms
SLBusiness powerbook - 0.031ms

-Cenji.

Given such low numbers, it's possible that your sim is on a server with less than 3 other sims. I've seen this happen on my region, with drastic reductions in script time being the result. Anyway, I think actually counting out the script time "used" by certain scripts is probably not a useful strategy, because this can vary due to any number of circumstances in the sim. The important part is just that the empty scripts do, in fact, use a finite amount of script time.

I just did this, and script frame time increased from 0.3ms to 0.7ms then dropped to 0.6ms. To get it over 2.3 ms took 740 empty scripts.

I don't believe that mono will have any effect whatsoever on the script overhead. These scripts are not execuring any LSL bytecodes at all, all the overhead that's being measured is in the event system.

I think this has to do with sim classes. The underlying discovery still remains.

I am not a script writer but like to use scripted objects. BUT I am also concerned about the effects of scripts on my SIM.
1. Is there a way to get a listing / count of scripts on my property as well as on my avatar?
2. Do scripts in my inventory have any effect on the SIM as well?

Thanks

#2 its not running unless its inside of a prim thats out in the world, so no its just text sitting in your little chunk of the asset server

#1 - Script times lists are only available to Sim owners and managers. On the mainland this would be The Lindens.

An interesting thing to note: Scripts running in attachments do not show on this list, but if the avatar sits on something, the object they are sitting on will show a total time for all the scripts that are running in the avatars attachments.

I read this a long time ago and just assumed it was a bug that would get corrected, but apparently not. It's really disconcerting not only because it means CPU is consumed by the 99% of prim water that retains the dormant llTextureAnimation() script, for example, but also because of what it may mean for the sim performance characteristics of basic scripting constructs. If something as basic as event dispatching isn't handled sensibly, it's hard to guess what other assumptions are wrong. So the question is: Do we have any kind of real data about, for example, the performance impact of *closed* versus *open* llListen()s? Or, as another example, the difference in impact between, say, llSetTexture() and the corresponding llSetPrimitiveParams() rule list?

I have noticed that scripts in one object get less scheduled time slots than scripts in discrete objects. When I link together all of the scripted stones in my Go board they behave sluggishly. When each stone is unlinked its script gets scheduled more speedily. So I bet that N scripts in a prim would have less sim impact than N scripts in N (unlinked) prims. It would also be interesting to see what happens when all of the prims are linked.

If true, this is interesting. Do you have any further info on this Argent?

You see, I seem to remember finding once (a while back) that having a lot of defined list globals at the start of a script would increase its idle time. Changing things so that the global lists were only declared, and moving the definitions to state_entry, reduced the idle time... which doesn't seem to support that it's only the event system causing this.

Any comments?

So, if 128 scripts can affect server performance while 128 prims do nothing, then why such the frugal limits on quantity of prims per parcel? A limit of quantity of scripts per parcel seems better. Perhaps it is too complicated for the control.

What we're measuring here is ONLY the "scirpt time" impact on a sim. Prims themselves impact sim performance in different ways (time sending updates, physics time, etc).