Scripts and Lag

As LOW as 52 FPS? What are you running?

Please tell me you're joking. If not, tell me who will head the lag control commission so I can go kiss some ass. Thanks.

It was as low as 52 FPS because the spa has tons of running water, thus active scripts everywhere, but also I had a large number of active listen scripts. Cutting back on those (now buying furniture without listen scripts exclusively) seems to have helped tremendously. Also, even with a gigantic waterfall and streams running through underground grottos, I found ways to eliminate excessive water where it wasn't really needed for the look or effect of the place so I am happy to say that we now average about 180 fps. Maybe not great, but much much better. ty.

Persephone - are we talking about individual client fps, or sim fps ?
Your numbers make no sense to me.
They seem too high for the first, too low for the second?

Surely nobody runs at 180fps client, and at 52 a sim is just about dead ?

Well written scripts don't cause nearly as much lag as people think.

Owning several casinos, I have from time to time had to deal with dingleberries who blame me for everything laggy about the sim. After all, "laggy casino" seems to be one word in many people's vocabulary.

For example, some 'tard (I forget who and even if I did remember I cant post it to the forums lol) tried to insinuate that my place in Tan was the cause of simFPS staying below 100 all the time (he/she is one of those sysadmin types - you know, the kind who puts their resume' in their sig). Well, in fact it was a massive prim build with lots of listens that was causing the lag. Since that build has been removed (followed by an immediate jump in simFPS!), I have added many many MORE "laggy casino games" to my place. SimFPS in Tan now ... over 1000 most of the time. Bear in mind Tan is one of the "old laggy sims".

So what does this show? A few things.

1. Well written, efficient scripts do not cause much lag at all.

2. Self proclaimed "experts" are not always right. Many times they are in fact 'tards who know a couple of things. I havent met too many people in SL who seem to have actual enterprise level development experience in a lead position. Many *say* they do, but all it takes is a few minutes talking to them to determine they just graduated from college within the last few years (at best! - I suspect many are still *in* school!). So be wary of tech advice. It may or may not help.

3. Testing goes a long way. When deploying scripted objects, keep the debug window open. Watch any impact to the simFPS. Keep an eye on it.

4. Re - read number 3.

5. Pay particular attention to number 3.

With Regards,
Antagonistic Protagonist

EDIT: Fixed some typos in an ongoing effort to avoid the wrath of the Red Pen Brigade.

This statement is incorrect. Green updates indicate a change that triggers object creation or deletion. Blue updates indicate partial object updates, where the sim only sends a few parameters of the object (such as a new position, for example) to the clients. Red updates indicate full object updates, where many (or all) parameters of the object are sent to the client. Its best to avoid a frequent number of red updates, because they eat bandwith.

This is derived from a question asked directly to a Linden (and its also posted on the LSL Wiki under lag)

In fact, most of the information posted in this thread is already up on that page.
==Chris

First I would like to say, everything Im saying here, ive learned for myself not going on the hearsay of others. By doing my own controlled experiments.

llListen,
Scripts that use listen events cause lag, "as everything cube or torus does"
THE CHANNEL DOES NOT MATTER. I have tested by rezing an equal amount of objects "100" , llListen'ing on channel 0 and then on a nonzero channel. and watching sim cpu and fps. Running the test 3 times shows each time the same effect, The channel does not matter, simply the presences of a listen event draws on sim performance EQUALLY.

If you listen on chan 0 and talk on chan 1, = lag,
listen on chan 0 and talk on 0 = lag
listen on 1 and talk on 0 = lag
listen on 1 and talk on 1 = lag. all equal.
IF the scripts are triggered due to your conditional statements in the listen, ie, theres more code other than simply listen(integer chan, string name, etc etc) Then yes obviously theres more draw.

SIM FPS.
"This im not 100% sure on, but all clues point to it, and even lindens have told me,
(well its complicated but anything over 100 fps is negotiable.)"
heregoes...
I believe Sim fps is a sliding scale.
Rezing an object in a sim running at 1000 fps. that brings that sim down to 900 Will bring a sim running at 100 fps to 90. Aproxamatly.
And as stated above. On the phone with LL I was told anything over 100FPS is negotiable.

Finnaly, I believe the 2 largest hits on sim performance are.....
Physics, and AGENTS "ie people, or the presence of an avatar in a sim.".

"just wait till 1.6 when we will have every other parcel streaming movies, and using some sort of llSensorRepeat + llPlayPacleMediaList script..."

Both are sim FPS. and Yes! it was just about dead. I manage the hotsprings spa for Perse, and Ice Brodie was kind enough to give us a box that tracks sim FPS. Is there a way to check for property FPS to see how we are in relation to others in the sim? We really do want to be good neighbours, but we also want to keep our pretty waterfall.

I dunno..

Just gonna have to test all this for myself in the end.

This doesnt fit:
I rezzed 250 prims in a 1000fps sim, each with a listen running.

Once things settled, fps had hardly dropped at all. I wasn't testing, but working, so I didnt write the numbers down.

Then I shouted at them.

A brief drop by nearly 500fps to 500fps, as they all executed conditional tests.

Then back to nearly 1000.

Delete the lot - hardly any improvement.

Suggests that just listening doesnt matter much if you're not hearing anything.

Can this be right or am I hallucinating? I'll go back and check carefully when I have time.

Seeing as how if there's nothing to cause a listen event to execute, it wont, yeah- this is perfectly sane.

If a tree falls in SL and there isn't anyone there to hear it, does it cause lag?

More of my thoughts...

The problem with listeners is that they have a RANGE. They "hear" within (at least) three ranges -- whisper, say, and shout. That means that every time you "speak", SL must know what listeners are in range, and which are not. The more avatars there are chatting and moving around, the more work it is for SL to figure out which listeners are in range and send the message to them all. Then, every listener that gets the message has to process it.

I believe that listeners (and sensors in general) mainly cause a problem when there are multiple chatty avatars moving around nearby.

Also, don't forget that there are THREE different kinds of "lag":

1) The Sim gets overworked (i.e., the server computer at Linden Labs is asked to do too much)
2) Your desktop computer gets overworked (i.e., your desktop PC and its graphics card are asked to do too much)
3) The wire between the above two is overflowing (i.e. too much information is being sent from the Sim server to your desktop computer.)

Different things cause different problems for each of these three components.

Nothing "always causes lag". Lag is the result of overloaded equipment. Until the various scripts/textures/prims reach a certain threshhold, no problem. You reach the limit of what the equipment can do, THEN lag.

As so often reported, Avatars are the number one resource hog in SL. Twenty Avatars in one place, slog city. I think its safe to say that Listeners, Sensors and avatar attachments have a tendency to magnify the resources needed per-avatar, so if you have a lot of them going on, then you hit the limits with fewer avatars. It is quite possible to get enough going on that even one avatar is too much.

Buster