measuring script efficiency

I have a customer who's (rightly) worried about the impact of script behavior on overall sim performance.

Based on my interpretation of the ctrl-shift-1 screen, physics, prims, and all that get whatever time they need, and scripts get whatever time is left over (though perhaps with some minimum guarantee). Is this correct?

How can I measure the efficiency of my scripts? BTW, I'm a real-time programmer with nearly 30 years of experience, so I understand the usual stuff about performance. (I've written the advice to programmers for two companies, including tips for writing scalable code used by my current employer with over 10K software engineers).

In particular, I'd like to measure the runtime costs of potentially inefficient operations like scans. I want to be able to give my customer quantitative answers, such as, "you can deploy N of these objects configured XYZ and that will consume K msec of script time per second, on average.

What tools can I use to do the measurement? I can probably borrow a sim with little or no activity for the measurement, if necessary.

Thanks!

I don't know about the mainland, but on an island, if you're an estate manager, you can pull up info on the script time consumed by a specific script. That will give you more detailed info than the ctrl-shift-1 thing, which is an aggregate for all the sims in the script.

Search this forum for guidelines. Also, remember that completely idle scripts take up scheduler time (for reasons unknown to me), and so there's a rough limit of about 5000-6000 scripts per sim, after which sims start to struggle, even if all those scripts only have an empty state_entry handler. Again, look through this forum, this has been discussed.

Go to an empty sim, remove all attachments, and wear/rez your object in question and watch script time and IPS. On the northern continent there's a lake area composed of 4 or 5 pure water sims, all owned by gov linden, almost all are always empty. Full build/script permissions and a 60 minute return time make them great scripting sandboxes and evaluation areas.

Seem to be pretty good recommendations so far. One thing I think should be added: While testing your script(s) in an empty sim will give you a pretty good baseline for any of your scripts relative to one another, there are the usual factors to remember.

1) The sim may not be running on the same hardware as every other sim, so how much time the script takes here might be different than there.

2) Some things, like listens and sensors, will take more time the more people are around. Obvious , but still something people don't take into account. A script with 20 listens might take very little time if nobodies talking. (ps ~ nobody should be using 20 listens, just an example).

3) The slower a sim is running the more overhead a script might take if it's causing frequent updates. The reason seems to be network processing overhead. This also increases the more avatars are observing updates your script might be causing.

As for giving them quantitative answers. The way I've done it in the past is actually setting up a benchmark object, which is an object that runs several looping scripts (doing something like setting color or texture) and counts the iterations they get through in a given amount of time. Do this in the area where your scripts are to be deployed. Do it before deploying them, and then try it a few times with more deployed each time. It will be a little shaky, and more so if there's heavy traffic coming and going in the area, but it should give you a set of fairly accurate datapoints to reference and use to give recommendations.

And just so you know, even with the best evidence I could give, I've still been accused of lagging a sim .

You're going to laugh but the blinky light theory holds true in this case, only slightly inverted. If the lights blink faster it must be working harder, if there are no lights, it's probably not doing much. So, if you know your script isn't causing lag, but you're still being accused, cut down to the minimum bells and whistles (ie metaphorical blinky lights) because it'll avoid the psychological effect. Who knows it might even actually lag less .