how fast is llSetLinkPrimitiveParamsFast

As noticed before, the new server version knows an interesting function, llSetLinkPrimitiveParamsFast. This fnction should set parameters of other prims in linkset delay-free. This is important for the new design of the SDKs, and makes interesting to measure how fast this function realy works.

The idea of how to test that is simple: Call the function multiple times and measure how long the bunch of calls took. Additionally, observing the linkset while the test is running would give also the feeling of the function speed. The test script should also call the function llSetLinkPrimitiveParams for reference test: this function does the same work but has build-in delays. This will be our test script:

integer steps = 10;
float   delta = 0.25;
vector  white = <1.0, 1.0, 1.0>;

testOldStyle(integer num) {
    integer step;
    for (step = 0 ; step < steps ; ++step) {
        float alpha = 0.0;
        while (alpha < 1.0) {
            vector color = <1.0, 1.0, alpha>;

            integer i;
            for (i = 1 ; i <= num ; ++i) {
                llSetLinkPrimitiveParams(i, [
                    PRIM_TEXT, (string)i, color, 1.0,
                    PRIM_COLOR, ALL_SIDES, white, alpha]);
            }

            alpha += delta;
        }
    }
}

testFastStyle(integer num) {
    integer step;
    for (step = 0 ; step < steps ; ++step) {
        float alpha = 0.0;
        while (alpha < 1.0) {
            vector color = <1.0, 1.0, alpha>;

            integer i;
            for (i = 1 ; i <= num ; ++i) {
                llSetLinkPrimitiveParamsFast(i, [
                    PRIM_TEXT, (string)i, color, 1.0,
                    PRIM_COLOR, ALL_SIDES, white, alpha]);
            }

            alpha += delta;
        }
    }
}

default {
    state_entry() {}

    touch_start(integer num) {
        num = llGetNumberOfPrims();
        integer time;
        
        llSay(0, "::: Test params...");
        llSay(0, "::: rounds: "+(string)steps);
        llSay(0, "::: prims: "+(string)num);
        llSay(0, "::: steps: "+(string)llCeil(1.0/delta));

        llSay(0, "::: Test: Old style...");
        time = llGetUnixTime();
        testOldStyle(num);
        time = llGetUnixTime()-time;
        llSay(0, "::: Test end: "+(string)time+" seconds");

        llSay(0, "::: Test: Fast style...");
        time = llGetUnixTime();
        testFastStyle(num);
        time = llGetUnixTime()-time;
        llSay(0, "::: Test end: "+(string)time+" seconds");
    }
}

Ok This script goes into a linkset with, say, 25 primitives, called testSPPF. Touch it. After a while (the test object is hugelly busy with switching the transparency and hover text) this result appears in the chat:

[10:54]  testSPPF: ::: Test params...
[10:54]  testSPPF: ::: rounds: 10
[10:54]  testSPPF: ::: prims: 25
[10:54]  testSPPF: ::: steps: 4
[10:54]  testSPPF: ::: Test: Old style...
[10:58]  testSPPF: ::: Test end: 230 seconds
[10:58]  testSPPF: ::: Test: Fast style...
[10:58]  testSPPF: ::: Test end: 5 seconds

The effect for script accelerating is obvious: Calling of llSetLinkPrimitiveParams 1000 times took 230 seconds, i.e. we had 230ms average delay for this function. (the wiki says about 200ms, so the server was in a verry good state). Calling 1000 times of llSetLinkPrimitiveParamsFast function took just 5 seconds, the average delay was even 5ms per call.

Much better to see is the visual effect. While in the first test one could very good watch the changing wave, slowly changing the linkset prim for prim. In the second test the wave is nearly not seen. Sometimes one can see in which direction it goes, sometimes one just notices changing of all 25 prims at once.

How fast the changing reallly looks like, depends surelly on the server state (it can take a break in the middle of the process) and even the internet connection, since the viewer must be told to change parameters of these and those prims.

The result of the test

The idea to use a single script for maniplating many prims should work fine also with much more than 25 prims per working script. But than you will loose the concurrency effect and experience a changing wave. Thus you need a reasonable balance between the script load and change concurrency by selecting an appropriate number of prims for one working script.