0008003: [OS FUNCTION IMPROVEMENT REQUEST] osForceCreateLink work slowly

(0032464)
UbitUmarov (administrator)
2017-11-27 08:35

spec says there is a 1s penalty per function call.
each function call does link object.
so 1S penalty per object link.

(0032498)
djphil (reporter)
2018-01-12 05:58

Hmmm great maths!
Heuuu, and you find that normal ... ?

I saw a patch proposed but will one day be applied ?
http://opensimulator.org/mantis/view.php?id=8267 [^]

Many functions have a delay, SL on a wiki page dedicated to this.
http://wiki.secondlife.com/wiki/LSL_Delay [^]

But SL scripts engine is still a lot faster than OS ...

(0032499)
mewtwo0641 (reporter)
2018-01-12 19:51
edited on: 2018-01-12 19:51

Hi djphil, I tried to test for this issue using OS master and compared performance of osForceCreateLink() vs. llCreateLink() and they appear to be exactly the same. Also ran the script (with the OSSL bits commented out so it would use llCreateLink()) on SL and got virtually identical performance results give or take a second or two for lag.

For testing I used a group of 16 prims arranged in a 4x4 grid similar to the below and tested both osForceCreateLink() and llCreateLink().

[*] [ ] [ ] [ ] [ ]
     [ ] [ ] [ ] [ ]
     [ ] [ ] [ ] [ ]
     [ ] [ ] [ ] [ ]

where [*] is the prim calling osForceCreateLink()/llCreateLink() and the [ ] are the prims to be linked to [*]

When linked individually resulted in appx 16 seconds wait time while the script worked through linking each prim to itself.

If I link some of the [ ] prims ahead of time before letting the script do linking; something like this:

[*] [A] [A] [B] [B]
     [A] [A] [B] [B]
     [C] [C] [D] [D]
     [C] [C] [D] [D]

where each letter group is a group of prims linked, I now have 4 objects linked in a 2x2 grid; A is 4 linked prims, B is 4 linked prims, etc. Letting the script link these groups together resulted in appx 4 seconds total to link everything.

Results from both tests I get seem to be expected judging from the results I got from repeating the test on SL.

Script Used For Testing:

string ValidLinkName = "CreateLinkTesting"; //Only attempt to link objects that are named this
float Range = 20.0; //How far to search for objects to link
integer UseOSSLLinkCreate = TRUE; //If TRUE then use osForceCreateLink(); if FALSE use llCreateLink() to create links

default
{
    touch_start(integer num)
    {
        llRequestPermissions(llDetectedKey(0), PERMISSION_CHANGE_LINKS);
    }

    run_time_permissions(integer perm)
    {
        if(perm & PERMISSION_CHANGE_LINKS)
            llSensor("", "", PASSIVE|ACTIVE, Range, TWO_PI);
    }

    no_sensor()
    {
        llSay(0, "No objects were found to link.");
    }

    sensor(integer num)
    {
        integer i = 0;

        for(i = 0; i < num; i++)
        {
            key thisKey = llDetectedKey(i);

            if(llKey2Name(thisKey) == ValidLinkName)
            {
                if(UseOSSLLinkCreate)
                {
                    llSay(0, "osForceCreateLink(): " + (string)thisKey);
                    osForceCreateLink(thisKey, LINK_THIS);
                }

                else
                {
                    llSay(0, "llCreateLink(): " + (string)thisKey);
                    llCreateLink(thisKey, LINK_THIS);
                }
            }
        }
    }
}

(0032502)
djphil (reporter)
2018-01-14 14:08

Hi mewtwo0641, you demonstrate something we already know.
I ask an improvement of this delay because in practice we do not have the patience to wait 5 minutes to obtain many linked prims. This limits the possibilities of creation in certain cases.

(0032503)
Chris Weymann (reporter)
2018-01-14 17:34

Hi djphil,

you can change the delay in the OpenSim.ini

[XEngine]
; Sets the multiplier for the scripting delays
ScriptDelayFactor = 1.0

Set ScriptDelayFactor = 0.0 to disable the delay.

(0032504)
djphil (reporter)
2018-01-14 18:36
edited on: 2018-01-14 18:37

Hi Chris, thanks for the info, the prims are fast now.

This parameter seems to act on all the functions with delay.
The patch proposed by tampa allows to act individually. Is better!
It's better if we keep some delays

Another problem detected, with DelayFactor on 0 or 1
I created +/- 300 prims and put the script in a prim at the center of all prims
I found only 16 prims are linked when I click on the prim in the center
Where were the other 284?

It seems there is a problem there ...
The Wiki SL does not speak of any limitation as to the number of prims to link ...
http://wiki.secondlife.com/wiki/LlCreateLink [^]

(0032505)
Chris Weymann (reporter)
2018-01-14 18:46

http://wiki.secondlife.com/wiki/Sensor [^]

"A sensor will only return the first 16 objects/avatars found."

(0032506)
djphil (reporter)
2018-01-14 18:48

True :) Sorry

(0032509)
djphil (reporter)
2018-01-14 19:24

What a pleasure to see llRezObject without delay! :)

default
{
    state_entry()
    {
        osForceBreakAllLinks();
    }

    touch_start(integer n)
    {
        n = 250;
        while(--n)
        {
            llRezObject("Object", llGetPos() + <-5.0 + llFrand(5.0), -5.0 + llFrand(5.0), 
-5.0 + llFrand(5.0)>, <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 1);
        }
    }

    object_rez(key target)
    {
        osForceCreateLink(target, LINK_THIS);
    }
}

Satisfactory result with 250 prims.

Really apply the patch 0008267 would be nice!

(0032510)
mewtwo0641 (reporter)
2018-01-14 21:23

Hi djphil, I apologize; I thought that the report was about an issue with the two functions rather than a requested change in behavior.

I looked through the code handling llCreateLink() and osForceCreateLink() and found that they both call the same method to handle linking of the prims and the delay is done within that method; which was expected. I think that it would be a bit difficult to change it for just osForceLinkCreate() since it would also affect llCreateLink() in doing so.

Even if patch 8267 was applied, from what I can tell, changing the delay for it would still affect both functions.

(0032511)
tampa (reporter)
2018-01-14 21:30

Not like it would be that difficult to separate those two in terms of their delays, but it is unlikely that the patch will ever be accepted seeing as there is a concern with it being used for spam(even if there are 1000 more effective ways to spam).

You can apply the patch yourself however, which is not that difficult to do :)

(0032516)
djphil (reporter)
2018-01-23 03:45

The spam problem is a fake problem because we can already set ScriptDelayFactor to 0.0
The patch 0008267 would precisely fine tune the different delay and thus fight significantly on spam although it can spammer 1000 other ways as said tampa.

The individual setting proposed by the patch would be greatly appreciated :)

(0032519)
BillBlight (developer)
2018-01-23 05:20
edited on: 2018-01-23 05:22

Actually ScriptDelayFactor, does not override the hardcoded delays built into LSL, if that was the case there would be no need for the patch.

But you are right, I can think of 100 ways to bring down a sim that does not require any of these functions ..

(0032520)
djphil (reporter)
2018-01-23 05:27

I put 0.0 and I have no delay. This is normal, even if it does not change the actual value in the code, multiplying 1x0 or 2x0 or 100x0 will always be 0 :)

(0032521)
BillBlight (developer)
2018-01-23 05:30

Well, from what I have seen from the code, that is added to the built in delays, does not override , I might be wrong, but I don't think the script delay factor is supposed to do that ..

(0032522)
BillBlight (developer)
2018-01-23 05:36
edited on: 2018-01-23 05:37

seems to me that that delay is for firing the script itself, not for each function ..

        protected virtual void ScriptSleep(int delay)
        {
            delay = (int)((float)delay * m_ScriptDelayFactor);
            if (delay == 0)
                return;

            Sleep(delay);
        }

and ..

            // Make sure loops aren't actually being terminated by a script delay wait.
            xEngineConfig.Set("ScriptDelayFactor", 0);

(0032523)
UbitUmarov (administrator)
2018-01-23 05:38

just to update your expectation levels on this issue.
i personaly have no plans to change this or add Tampa patch for configurable delays into core in near future.
(and yes i do have some reasons for that)

Notes
(0032464) UbitUmarov (administrator) 2017-11-27 08:35	spec says there is a 1s penalty per function call. each function call does link object. so 1S penalty per object link.

(0032498) djphil (reporter) 2018-01-12 05:58	Hmmm great maths! Heuuu, and you find that normal ... ? I saw a patch proposed but will one day be applied ? http://opensimulator.org/mantis/view.php?id=8267 [^] Many functions have a delay, SL on a wiki page dedicated to this. http://wiki.secondlife.com/wiki/LSL_Delay [^] But SL scripts engine is still a lot faster than OS ...

(0032499) mewtwo0641 (reporter) 2018-01-12 19:51 edited on: 2018-01-12 19:51	Hi djphil, I tried to test for this issue using OS master and compared performance of osForceCreateLink() vs. llCreateLink() and they appear to be exactly the same. Also ran the script (with the OSSL bits commented out so it would use llCreateLink()) on SL and got virtually identical performance results give or take a second or two for lag. For testing I used a group of 16 prims arranged in a 4x4 grid similar to the below and tested both osForceCreateLink() and llCreateLink(). [] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] where [] is the prim calling osForceCreateLink()/llCreateLink() and the [ ] are the prims to be linked to [] When linked individually resulted in appx 16 seconds wait time while the script worked through linking each prim to itself. If I link some of the [ ] prims ahead of time before letting the script do linking; something like this: [] [A] [A] [B] [B] [A] [A] [B] [B] [C] [C] [D] [D] [C] [C] [D] [D] where each letter group is a group of prims linked, I now have 4 objects linked in a 2x2 grid; A is 4 linked prims, B is 4 linked prims, etc. Letting the script link these groups together resulted in appx 4 seconds total to link everything. Results from both tests I get seem to be expected judging from the results I got from repeating the test on SL. Script Used For Testing: string ValidLinkName = "CreateLinkTesting"; //Only attempt to link objects that are named this float Range = 20.0; //How far to search for objects to link integer UseOSSLLinkCreate = TRUE; //If TRUE then use osForceCreateLink(); if FALSE use llCreateLink() to create links default { touch_start(integer num) { llRequestPermissions(llDetectedKey(0), PERMISSION_CHANGE_LINKS); } run_time_permissions(integer perm) { if(perm & PERMISSION_CHANGE_LINKS) llSensor("", "", PASSIVE\|ACTIVE, Range, TWO_PI); } no_sensor() { llSay(0, "No objects were found to link."); } sensor(integer num) { integer i = 0; for(i = 0; i < num; i++) { key thisKey = llDetectedKey(i); if(llKey2Name(thisKey) == ValidLinkName) { if(UseOSSLLinkCreate) { llSay(0, "osForceCreateLink(): " + (string)thisKey); osForceCreateLink(thisKey, LINK_THIS); } else { llSay(0, "llCreateLink(): " + (string)thisKey); llCreateLink(thisKey, LINK_THIS); } } } } }

(0032502) djphil (reporter) 2018-01-14 14:08	Hi mewtwo0641, you demonstrate something we already know. I ask an improvement of this delay because in practice we do not have the patience to wait 5 minutes to obtain many linked prims. This limits the possibilities of creation in certain cases.

(0032503) Chris Weymann (reporter) 2018-01-14 17:34	Hi djphil, you can change the delay in the OpenSim.ini [XEngine] ; Sets the multiplier for the scripting delays ScriptDelayFactor = 1.0 Set ScriptDelayFactor = 0.0 to disable the delay.

(0032504) djphil (reporter) 2018-01-14 18:36 edited on: 2018-01-14 18:37	Hi Chris, thanks for the info, the prims are fast now. This parameter seems to act on all the functions with delay. The patch proposed by tampa allows to act individually. Is better! It's better if we keep some delays Another problem detected, with DelayFactor on 0 or 1 I created +/- 300 prims and put the script in a prim at the center of all prims I found only 16 prims are linked when I click on the prim in the center Where were the other 284? It seems there is a problem there ... The Wiki SL does not speak of any limitation as to the number of prims to link ... http://wiki.secondlife.com/wiki/LlCreateLink [^]

(0032505) Chris Weymann (reporter) 2018-01-14 18:46	http://wiki.secondlife.com/wiki/Sensor [^] "A sensor will only return the first 16 objects/avatars found."

(0032506) djphil (reporter) 2018-01-14 18:48	True :) Sorry

(0032509) djphil (reporter) 2018-01-14 19:24	What a pleasure to see llRezObject without delay! :) default { state_entry() { osForceBreakAllLinks(); } touch_start(integer n) { n = 250; while(--n) { llRezObject("Object", llGetPos() + <-5.0 + llFrand(5.0), -5.0 + llFrand(5.0), -5.0 + llFrand(5.0)>, <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 1); } } object_rez(key target) { osForceCreateLink(target, LINK_THIS); } } Satisfactory result with 250 prims. Really apply the patch 0008267 would be nice!

(0032510) mewtwo0641 (reporter) 2018-01-14 21:23	Hi djphil, I apologize; I thought that the report was about an issue with the two functions rather than a requested change in behavior. I looked through the code handling llCreateLink() and osForceCreateLink() and found that they both call the same method to handle linking of the prims and the delay is done within that method; which was expected. I think that it would be a bit difficult to change it for just osForceLinkCreate() since it would also affect llCreateLink() in doing so. Even if patch 8267 was applied, from what I can tell, changing the delay for it would still affect both functions.

(0032511) tampa (reporter) 2018-01-14 21:30	Not like it would be that difficult to separate those two in terms of their delays, but it is unlikely that the patch will ever be accepted seeing as there is a concern with it being used for spam(even if there are 1000 more effective ways to spam). You can apply the patch yourself however, which is not that difficult to do :)

(0032516) djphil (reporter) 2018-01-23 03:45	The spam problem is a fake problem because we can already set ScriptDelayFactor to 0.0 The patch 0008267 would precisely fine tune the different delay and thus fight significantly on spam although it can spammer 1000 other ways as said tampa. The individual setting proposed by the patch would be greatly appreciated :)

(0032519) BillBlight (developer) 2018-01-23 05:20 edited on: 2018-01-23 05:22	Actually ScriptDelayFactor, does not override the hardcoded delays built into LSL, if that was the case there would be no need for the patch. But you are right, I can think of 100 ways to bring down a sim that does not require any of these functions ..

(0032520) djphil (reporter) 2018-01-23 05:27	I put 0.0 and I have no delay. This is normal, even if it does not change the actual value in the code, multiplying 1x0 or 2x0 or 100x0 will always be 0 :)

(0032521) BillBlight (developer) 2018-01-23 05:30	Well, from what I have seen from the code, that is added to the built in delays, does not override , I might be wrong, but I don't think the script delay factor is supposed to do that ..

(0032522) BillBlight (developer) 2018-01-23 05:36 edited on: 2018-01-23 05:37	seems to me that that delay is for firing the script itself, not for each function .. protected virtual void ScriptSleep(int delay) { delay = (int)((float)delay * m_ScriptDelayFactor); if (delay == 0) return; Sleep(delay); } and .. // Make sure loops aren't actually being terminated by a script delay wait. xEngineConfig.Set("ScriptDelayFactor", 0);

(0032523) UbitUmarov (administrator) 2018-01-23 05:38	just to update your expectation levels on this issue. i personaly have no plans to change this or add Tampa patch for configurable delays into core in near future. (and yes i do have some reasons for that)

Issue History
Date Modified	Username	Field	Change
2016-08-21 05:40	djphil	New Issue
2016-09-01 12:23	djphil	Relationship added	duplicate of 0007871
2017-11-26 22:52	tampa	Relationship added	related to 0008267
2017-11-27 08:17	UbitUmarov	Relationship deleted	related to 0008267
2017-11-27 08:35	UbitUmarov	Note Added: 0032464
2018-01-12 05:58	djphil	Note Added: 0032498
2018-01-12 19:51	mewtwo0641	Note Added: 0032499
2018-01-12 19:51	mewtwo0641	Note Edited: 0032499	View Revisions
2018-01-14 14:08	djphil	Note Added: 0032502
2018-01-14 17:34	Chris Weymann	Note Added: 0032503
2018-01-14 18:36	djphil	Note Added: 0032504
2018-01-14 18:37	djphil	Note Edited: 0032504	View Revisions
2018-01-14 18:46	Chris Weymann	Note Added: 0032505
2018-01-14 18:48	djphil	Note Added: 0032506
2018-01-14 19:24	djphil	Note Added: 0032509
2018-01-14 21:23	mewtwo0641	Note Added: 0032510
2018-01-14 21:30	tampa	Note Added: 0032511
2018-01-23 03:45	djphil	Note Added: 0032516
2018-01-23 05:20	BillBlight	Note Added: 0032519
2018-01-23 05:22	BillBlight	Note Edited: 0032519	View Revisions
2018-01-23 05:27	djphil	Note Added: 0032520
2018-01-23 05:30	BillBlight	Note Added: 0032521
2018-01-23 05:36	BillBlight	Note Added: 0032522
2018-01-23 05:37	BillBlight	Note Edited: 0032522	View Revisions
2018-01-23 05:38	UbitUmarov	Note Added: 0032523