Script Time, and the Importance of Avatar Weight.

[ChinRey]

5 hours ago, Innula Zenovka said:

What impact do running but inactive scripts (e.g. a door script that's just waiting for someone to touch the door, or a chair waiting for someone to sit on it) have, as compared to a couple of normally-outfitted avatars just walking around chatting?

Not much but not much is not the same as nothing at all and this spinning ("spinning" is yet another word for "busy waiting" or "busy idling" btw) is tapping regions of a significant amount of  resources they could have put to better uses.

I don't think we should compare the two because. Over-scripted avatars are the user's responsibility and it's up to us to deal with it. The spinning is a fundamental flaw in the software and Linden Lab's responsibility. As I said, the most worrying aspect of this is that LL doesn't even realize that this isn't normal for a computer program. Professional programmers shuld know better.

[Wulfie Reanimator]

23 minutes ago, ChinRey said:

The spinning is a fundamental flaw in the software and Linden Lab's responsibility. As I said, the most worrying aspect of this is that LL doesn't even realize that this isn't normal for a computer program. Professional programmers shuld know better.

Kind of a weird thing coming from someone who admittedly has no knowledge of this topic and has only heard second-hand musings from another user who has no insight into the system being used. (No offense to Animats, I respect him.) You can't say "LL doesn't even realize," they are most likely aware of this but the cost of restructuring a major part of the server architecture for a few milliseconds gain in a situation where no critical harm is being suffered is probably not worth it. It is likely that -- like many things in SL -- the foundation was built on shaky knowledge and improved over time, but the core is still there and at this point it is almost impossible to change without a complete redo. And LL has attempted a complete redo, it's called Sansar.

And this isn't even about "professional programmers," big companies make stupid decisions to no fault of the developers who might see the issues but have no power to influence the decisions. (Not to mention that "professional programmers" make lots of stupid decisions too, there are so many jokes and stereotypes related to programming that are very deeply rooted in a depressing reality.)

Edited May 22, 2019 by Wulfie Reanimator

[ChinRey]

7 hours ago, Love Zhaoying said:

Which part, the # scripts?

The worrying part is that the load stats already are that high. What will happen when people have filled up their homes with furniture with animation scripts, maybe a pathfinding pet or two etc., etc.

The numbers are actually remarkably similar to those of one of my own regions, Coniston, a region that has been developed for almost six years with far more housing units, may main store and at least 14 (I've lost count) full sim sky platforms and according to LL it's a heavy region.

Then again, it may be the avatars. There were eight of them in the region (nine when I arrived but I used one of my low lag non-mesh alts). I don't know how much of the load they accounted for and we're not going to see that many of them once things have settled down a bit.

So it's a heads up, not an alarm.

[ChinRey]

1 hour ago, Wulfie Reanimator said:

You can't say "LL doesn't even realize,"

Apparently that was their response. I only have Animats' word for it of course , I wasn't there, and now that he's rejoined the thread, there's no need for me to say anything more about it.

 

1 hour ago, Wulfie Reanimator said:

they are most likely aware of this but the cost of restructuring a major part of the server architecture for a few milliseconds gain in a situation where no critical harm is being suffered is probably worth it. It is likely that -- like many things in SL -- the foundation was built on shaky knowledge and improved over time, but the core is still there and at this point it is almost impossible to change without a complete redo.

Yes, that's a far more likely explanation but if that's the case, why don't they say so?

Except for the "shaky knowledge" part. The core of lsl was not created by some juinor programmer but by LL's two former CTOs, Cory Ondrejka and Andrew Meadows, and they certainly knew better. It's more likely that it's because it was a rush job. According to Ondrejka, SL wasn't supposed to have any scripting functionality at all. It was added as an afterthought (Ondrejka and Meadows actually wrote the entire LSL 1.0 in a single one-nighter work session) and they never expected it to become an important part of SL.

 

1 hour ago, Wulfie Reanimator said:

Kind of a weird thing coming from someone who admittedly has no knowledge of this topic

I can hardly claim to be an expert in this so I rely heavily on secondhand information here. But I did spend a year of my wasted youth studying computer technology at a university and I have written programs myself if that helps.

Edited May 22, 2019 by ChinRey

[ChinRey]

6 hours ago, animats said:

 

• At least for homestead sims, some limit is applied between 5 and 6 ms of script time per frame. This may mean that idle scripts are limited to a quarter of the possible script time. Or it may mean that homestead scripts are limited.

I think that actually is the maximum actual frame time allocated to a homestead sim. It's a quarter of a full sim so it makes sense. This is something I've seen before. According to the stats, the frame time allocated to a homestead is the same as that allocated to a full sim. If that is correct, an event should take four times as much frame time at a homestead but is clearly not the case. The only possible explanation is that the statistics are wrong and a homestead only have a quarter of the frame time they say it has.

I redid the test at a full sim, Sandbox Formosa. There were three scripts to start with I couldn't get rid of - it may have been my Firestorm bridge - but they shouldn't be significant to this illustration.

I suppose I can just post some screenshots of the stats - they should say it all.

Except for one unexpected and not really related observation. When I tried to remove all the prims as one bundle, I got the message they couldn't be deleted because of too many scripts. Seems we've got a way to override autoreturn here: just load your item with enough scripts and the sim won't be able to get rid of it.

 

[animats]

55 minutes ago, ChinRey said:

I think that actually is the maximum actual frame time allocated to a homestead sim. It's a quarter of a full sim so it makes sense.

I redid the test at a full sim, Sandbox Formosa. There were three scripts to start with I couldn't get rid of - it may have been my Firestorm bridge - but they shouldn't be significant to this illustration.

Yes, Simon Linden said at Server User Group today that I was hitting the Homestead sim limit. And as ChinRey has shown, there's a larger limit for full sims. Somewhere between 4000 and 7000 scripts doing nothing, a totally idle full sim runs out of script time.

The designers of SL probably never anticipated as many idle scripts as we seem to have today. 4000 scripts isn't rare on a mainland sim. Oz admitted today that this is indeed a big load on the system. This might get looked at by the dev team.

So now we have more insight on "how can this sim be overloaded when nothing is happening?"

[ChinRey]

2 minutes ago, animats said:

Oz admitted today that this is indeed a big load on the system.

That's exactly what we needed to hear.

Btw, here's Ondrejka's own account how lsl was created. http://ondrejka.net/metaverse memory/2008/01/22/lsl1.html

Not everybody's cup of tea but a few people might find it interesting.

[kiramanell]

1 hour ago, ChinRey said:

Not much but not much is not the same as nothing at all and this spinning ("spinning" is yet another word for "busy waiting" or "busy idling" btw) is tapping regions of a significant amount of  resources they could have put to better uses.

I don't think we should compare the two because. Over-scripted avatars are the user's responsibility and it's up to us to deal with it. The spinning is a fundamental flaw in the software and Linden Lab's responsibility. As I said, the most worrying aspect of this is that LL doesn't even realize that this isn't normal for a computer program. Professional programmers shuld know better.

 

Well, whatever spin we give on this, I'm not even sold on scripts 'spinning' at all. 'Spinning', to me, denotes some type of continuous, active loop. Animats wrote:

"One big problem, which I consider a bug in SL, is that scripts doing absolutely nothing use some time on every frame. The system asks them, on every frame, "You need to do anything?" The script says "No." This takes a tiny amount of time"

I would have thought the event-driven nature of scripts would not cause this alleged continuous polling by the system at all. Logical would be to just queue the event, and then signal the script that something is waiting. Scrips listeners obviously require the script to poll the chat history continuously (this could indeed be called 'spining'), at each frame; haven't tested it, but those could actually consume quite some time too.

[ChinRey]

6 minutes ago, kiramanell said:

Well, whatever spin we give on this, I'm not even sold on scripts 'spinning' at all. 'Spinning', to me, denotes some type of continuous, active loop.

Spinning is fairly commonly used as a synonym for busy idling but yes, it does have several other meanings too. I won't use it in this context anymore.

 

6 minutes ago, kiramanell said:

Scrips listeners obviously require the script to poll the chat history continuously (this could indeed be called 'spining'), at each frame; haven't tested it, but those could actually consume quite some time too.

There's another script efficiency question. Logically listeners should stack very well so multiple listens shouldn't add much more work load than a single one. I haven't tested it either but from what I understand, this is not the case.

Edited May 22, 2019 by ChinRey

[kiramanell]

23 minutes ago, animats said:

Yes, Simon Linden said at Server User Group today that I was hitting the Homestead sim limit. And as ChinRey has shown, there's a larger limit for full sims. Somewhere between 4000 and 7000 scripts doing nothing, a totally idle full sim runs out of script time.

The designers of SL probably never anticipated as many idle scripts as we seem to have today. 4000 scripts isn't rare on a mainland sim. Oz admitted today that this is indeed a big load on the system. This might get looked at by the dev team.

So now we have more insight on "how can this sim be overloaded when nothing is happening?"

 

And now we need some more insight on "How can this sim be running at all, wen something is happening?"

Thx for all your testing, though.

Edited May 22, 2019 by kiramanell

[kiramanell]

7 minutes ago, ChinRey said:

Spinning is fairly commonly used as a synonym for busy idling but yes, it does have several other meanings too. I won't use it in this context anymore.

 

Eh, don't worry about it. Clearly idle scripts are consuming more time than I thought; so much so more even, that we might as well call it 'spinning.'

[animats]

34 minutes ago, kiramanell said:

Well, whatever spin we give on this, I'm not even sold on scripts 'spinning' at all. 'Spinning', to me, denotes some type of continuous, active loop. Animats wrote:

"One big problem, which I consider a bug in SL, is that scripts doing absolutely nothing use some time on every frame. The system asks them, on every frame, "You need to do anything?" The script says "No." This takes a tiny amount of time"

I would have thought the event-driven nature of scripts would not cause this alleged continuous polling by the system at all. Logical would be to just queue the event, and then signal the script that something is waiting. Scrips listeners obviously require the script to poll the chat history continuously (this could indeed be called 'spining'), at each frame; haven't tested it, but those could actually consume quite some time too.

Not "spinning". That has a specific meaning in scheduling, where you're in a loop frantically testing for something to change.

Simon Linden said that they do the basic optimization of not waking up the Mono script interpreter when a script has no new events, but the overhead of making the check for an event pending is still non-zero. That's the problem. This is a classic operating system scheduler design issue and there are ways to schedule that avoid this problem. They're more complicated.  Scheduling tends to be an area of touchy code and I can understand LL's unwillingness to mess with that without good reason. I've worked on OS schedulers. It's easy to 1) break something, or 2) create a new and different performance problem.

Anyway, enough on this. It's getting looked at by LL, because they are getting lots of complaints about overloaded sims. Fixing this is probably cheaper than buying more hardware or paying higher AWS bills.

[Mari Moonbeam]

On 5/19/2019 at 11:30 PM, CoffeeDujour said:

here is no reason to wear your adult private parts while you are trying to sail a boat, or fly a plane, or even converse with your neighbour 😉 Turn that crap off !

I lie naked, except for private parts , on the floor of my undecorated house .   WINNING!

 

(But what if your parts can carry on a better convo than you can? C'mon, we've all dated one of those ).

[Coffee Pancake]

12 hours ago, kiramanell said:

Eh, don't worry about it. Clearly idle scripts are consuming more time than I thought; so much so more even, that we might as well call it 'spinning.'

When you have 10,000 of anything it's going to all add up to the point that's where the script engine appears to spend the bulk of it's time. even if individually they are using almost nothing.

One easy speed boost under these circumstances could well be to remove the code that records script time. Generating and recording statistics is far from free.

Just something to keep in mind as the complaint isn't "scripts run slow" it's "the numbers for scripts look bad" ...

Treat programmers like genies, be very careful what you wish for.

[ChinRey]

4 minutes ago, CoffeeDujour said:

Treat programmers like genies, be very careful what you wish for.

and don't rub them the wrong place way.

[Innula Zenovka]

@ChinRey Thanks for all your testing.   Sorry if you've mentioned it before but what script did you use for your tests?

I ask because it seems to me at least possible -- since I don't have any real idea of what's actually going on from frame to frame in the simulator -- that there could be a difference between a script that reacts to events external to the script -- someone says something on the public chat channel, so in the next frame the simulator has to check if there are any scripts listening on that channel and, if there are, which ones can hear what's been said, and assuming there are scripts within range, if they are listening to that particular av,   and then if appropriate the script has to process the message -- and one that reacts to events that directly affect the object containing the script -- someone sits down on the object, so it positions them and plays an animation.

I can see that a listener, or a repeating sensor or a timer require constant attention from the simulator but what happens with collision or touch events?    Does the simulator check every frame if someone has touched an item?   If it does, does it check that even for scripted objects that don't contain a touch* event?   Or does the object containing the script tell the simulator "someone has touched me, so I want you to send her a copy of the object in my contents/rotate me through 90 degrees/turn me green?

I just don't know how it works at that level.

[ChinRey]

46 minutes ago, Innula Zenovka said:

@ChinRey Thanks for all your testing.   Sorry if you've mentioned it before but what script did you use for your tests?

I only checked the performacne stats for idle script, the same as animats, except I did it on a full sim rather than a homestead, nothing more fancy than that. A very simple one, add more and more idle scripts and see how they affected the frame time, time dilation and such.

The script I used was simply the default code for new scripts, so they did include a touch_start() event, all scripts were identical and compiled in mono.

 

46 minutes ago, Innula Zenovka said:

If it does, does it check that even for scripted objects that don't contain a touch* event?

Very interesting question and the answer is yes. At least it does something with all the scripts.

Look at this one:

default
{
    state_entry(){
    }
}

I think most of us will agree that scripts don't get much simpler than that

Yet with 5120 of them (identical ones and complied in mono) running, region stats changed from:

to:

This quick test was done at Sandbox Verenda. There were other people at Sandbox Formosa, the one I used for the previous test.

Edited May 22, 2019 by ChinRey

[Innula Zenovka]

Thank you.   How soon after rezzing the 5120 test objects did you run the tests?    

I ask because the rule of thumb in the wiki is that 

Quote

Each idle script in an object adds 0.001 to 0.003 milliseconds per frame of script time usage

http://wiki.secondlife.com/wiki/LSL_Script_Efficiency#How_Fast_Does_That_Code_Run

So rezzing 5120 test objects with your simple script should add between 5.12 and 15.36 milliseconds per frame.  Since I suspect that so small and simple a script as yours should be towards the lower end of the scale but, nevertheless, the actual script time seems to be far closer to 0003, I'm wondering if that figure doesn't represent the time spent loading the scripts if the reading was taken only a short time after the objects were rezzed.    

In any event, while I agree it's better not to use resources unnecessarily and that, since we can't go anything about most of the things that place demands on the simulator -- avatar textures and activity -- we have to concentrate on micro-optimisations where we can.    

But nevertheless, I still pretty sure that, under normal circumstances (so not a combat or racing region) any advantages that can be gained by such optimisations are going to be hard to detect.    The only thing a script can lag simply by running (rather than actually doing potentially laggy things like a temp rezzer rezzing complex scripted objects very frequently) is another script.    If there's not enough spare time in the region to run all the scripts each frame then a percentage of them have to wait for the next frame.   It doesn't slow down anything else.

So if things are so finely balanced on the region that extra non-malicious scripts, competently written, are causing the region to take an appreciable performance hit that anyone can notice without watching the consoles, then it seems me that there must be something else, far more worrying, going on in the region too.

I'm not saying we should use unnecessary scripts.  I'm simply saying that I don't think we should make too great a fetish of it.

 

[Coffee Pancake]

7 hours ago, Innula Zenovka said:

But nevertheless, I still pretty sure that, under normal circumstances (so not a combat or racing region)

Don't tell the combat racing peeps or the racing combat peeps (and don't mix them up, they get angry), but it's the rate of agent updates that makes the difference, not how many region frames, or how fast things ran inside those frames that determines the fluidity of the experience.

Doesn't matter how much or how little the region accomplished, if it manages to tell you about it in a timely manner then it's academic.

There is also a huge difference between actual performance and perceived performance, and one would hope that the Lab have their foot on the scale heavily in favor of the latter.

The vast majority don't care (and don't even know) about the exact metrics of the script engine, they care about perceived end results in the broadest possible terms. Can I move? I clicked the thing, did it do the thing ? And so on. (These same people will also happily blame scripts for the terrible lag on a packed shopping region, and then crank up an area search while wearing an alpha animation based attachment, while the region owners aggressively pester mono about memory usage and eject "the bad" people).

Secondly no aspect of region load is linear in nature, especially once you enter a frame overflow condition, the impact on scripts can appear in the stats floater to be exponential (which is why scripts run is always around the high 90% or crashing though the floor).

[kiramanell]

9 hours ago, Innula Zenovka said:

Thank you.   How soon after rezzing the 5120 test objects did you run the tests?    

I ask because the rule of thumb in the wiki is that 

http://wiki.secondlife.com/wiki/LSL_Script_Efficiency#How_Fast_Does_That_Code_Run

So rezzing 5120 test objects with your simple script should add between 5.12 and 15.36 milliseconds per frame.  Since I suspect that so small and simple a script as yours should be towards the lower end of the scale but, nevertheless, the actual script time seems to be far closer to 0003, I'm wondering if that figure doesn't represent the time spent loading the scripts if the reading was taken only a short time after the objects were rezzed.    

In any event, while I agree it's better not to use resources unnecessarily and that, since we can't go anything about most of the things that place demands on the simulator -- avatar textures and activity -- we have to concentrate on micro-optimisations where we can.    

But nevertheless, I still pretty sure that, under normal circumstances (so not a combat or racing region) any advantages that can be gained by such optimisations are going to be hard to detect.    The only thing a script can lag simply by running (rather than actually doing potentially laggy things like a temp rezzer rezzing complex scripted objects very frequently) is another script.    If there's not enough spare time in the region to run all the scripts each frame then a percentage of them have to wait for the next frame.   It doesn't slow down anything else.

So if things are so finely balanced on the region that extra non-malicious scripts, competently written, are causing the region to take an appreciable performance hit that anyone can notice without watching the consoles, then it seems me that there must be something else, far more worrying, going on in the region too.

I'm not saying we should use unnecessary scripts.  I'm simply saying that I don't think we should make too great a fetish of it.

 

 

^^ I'm competely with you on this! Thank you for saying so!

[Leora Jacobus]

On 5/19/2019 at 7:44 PM, MajesV4 said:

...If we are going to have 20-30  residences per region we are going to have to make some compromises.. Adult furniture is also very script heavy but most can be turned off when not in use. ...

I do not understand that. Do I have to actively turn something OFF?

My bed (for example): if i click it - or sit on it - it gives me a menue: single - couple - adult. Then I choose an animation f.i. "daydream", later I can change to another. When I get up the menue expires. Are the scripts OFF then? Or have I to do something more?

[Marianne Little]

2 minutes ago, Leora Jacobus said:

I do not understand that. Do I have to actively turn something OFF?

My bed (for example): if i click it - or sit on it - it gives me a menue: single - couple - adult. Then I choose an animation f.i. "daydream", later I can change to another. When I get up the menue expires. Are the scripts OFF then? Or have I to do something more?

This thread is way over my head.

You know what I wish for? A "science is settled", with a summary of what we should do, what's not so important and what we don't have to do. I don't need to understand it. I just want some clear, short bullet points. 

It is very interesting with a debate and great for those who have the knowledge. I don't think I am in that category. 

 

[Wulfie Reanimator]

4 hours ago, Marianne Little said:

This thread is way over my head.

You know what I wish for? A "science is settled", with a summary of what we should do, what's not so important and what we don't have to do. I don't need to understand it. I just want some clear, short bullet points. 

It is very interesting with a debate and great for those who have the knowledge. I don't think I am in that category. 

The summary is roughly:

• Even the simplest script causes lag in large numbers, no matter how "low-lag" it is.
• Scripts contribute to script lag even if they are doing literally nothing.
   
• There is no practical solution to this problem, it is best for the user to just do nothing.
  • The only way to turn the scripts off completely is to select the object and go to..
    • Build > Scripts > Set scripts to not running
  • But this requires modify permissions to the object, so it cannot be done for every object.
  • This also requires you to turn the scripts back on manually before you can interact with them again.
  • And for this to be noticeably effective, it needs to be done to hundreds of scripts at the same time, maybe thousands depending on how many scripts are in the sim.

[WillowTenage]

After reading this, I became a little concerned with my own script usage as I have everything on my property set to a rez box.  What is the acceptable memory usage of a parcel, that will not lag out my neighbors?  At this moment, with everything rezzed in my house and yard I am using 8096 kb under parcel script memory, with about 40 scripts running, am I being a bad neighbor? 

 

 

Edited May 24, 2019 by WillowTenage

[Wulfie Reanimator]

1 hour ago, WillowTenage said:

After reading this, I became a little concerned with my own script usage as I have everything on my property set to a rez box.  What is the acceptable memory usage of a parcel, that will not lag out my neighbors?  At this moment, with everything rezzed in my house and yard I am using 8096 kb, with about 40 scripts running, am I being a bad neighbor? 

Don't worry about the reported memory usage. Scripts, by default, only report the maximum amount of memory they could potentially take, which is 64KB per script. The used amount is generally a lot less but you cannot find this out without being able to edit the script. There is no specific limit to "how much is too much," because it depends on the overall amount of scripts in the whole sim and the type of sim. If you have 40 scripts but the sim has 4000 scripts in total, you're almost certainly the least of the problems.

That said, 40 scripts is absolutely not bad for a parcel.

Edited May 24, 2019 by Wulfie Reanimator