Lag/load testing new creations/scripts - is there a tool available to test this???

Noting:
a) It seems to be an unwritten requirement that scripts/creations not cause too much lag &
b) best practice is that requirements be testable, with expected vs achieved results quantifiable

Is there (a Linden Labs released tool for example) a tool that can be used to quantify the lag/performance of a new creation to ensure it is acceptance from a community and Linden Labs perspective?

I'd personally feel more comfortable myself with my first creations knowing that they've been tested/verified/certified so to speak.

Tks
Greg

There is no such tool.

You can find the collected wisdom of the scripters on lag and less laggy scripts on the wiki.

Thanks for being a concerned scripter.

Shouldn't this be a key tool that we should ask for? Or in fact that Linden Labs should be offering to help minimise load on their machines?

What do people think?

You're kind of new here, eh?

"Ask for" is a term that one might naturally assume applies to a "service firm" that is structured around the traditional concept of "a firm that attends to the service desires of its customers"; Linden Lab is - shall we say - "non-traditional" in many regards, this one included.

The second part of your question is based around the assumption that Linden Lab understands the emergent properties of their software and can construct tools that aid in the analysis and optimization of the service they sell. You might come to this idea from looking at firms like Internet Hosting Services or Database Software Providers, both of which are similar to the line of business Linden Lab is in. Your intuition here would likely fail you as well, as they've always been a bit confused as to what line of business they in fact are in.

You get used to it after a while. Those are good questions, though; I wish the answers were better.

I actually posted such a request to the hotline, with an example of how it could be implemented as an estimate and then actual numbers. It was a follow-up to a (sadly all to brief) request for at least some better fineness of analysis of scripted object highlights.

It never got picked up that I'm aware of, but by all means nag on the hotline and votes pages...

What I suggested was a hypothetical timing system - function x takes y cycles typically, so you could get an approximate load indicator, and then a system of actually monitoring the demands of your script over an hour, day, week so you could see the real demands as well as any peaks (something that sends an email every 23 hours is probably low most of the time and high once (or occassionally twice) a day for example).

I'd be satisfied with a time function that gives you time in small enough units it could be used for print-debugging.

Has the time come for the SL scripting community to come up with their own standard of measure for scripts?.. 2 scripts can be used to measure the estimated compile time of one...using llSay or llMessageLinked and passing the time at reset (compile start) and the time to on Defaults state entry.. right?

1. I'm not sure a reset causes a re-compile, specially since the UI has separate menu options for reset and re-compile.

2. The time it takes for a script to compile can't really be used as an indicator of its run-time weight. Overall script size, yes, but a longer script isn't necessarily a busier script. You can write very simple scripts that will compile pretty quickly, but still use up every available CPU cycle:

default
{
    state_entry()
    {
        while (1)
        {
            llSay(0, "Something useless");
        }
    }
}

Back on topic... I agree, better debugging tools would be very helpful

Quite right Ziggster - Compiling is actually done by the client, not within SL.
In fact, when you recompile from the menu, your machine downloads the source from each prim, compiles it locally, and then re-uploads the compiled version.