Lag ~ Are The Rumours True?

In the never-ending search for ways to reduce lag I've bought a brand new computer with a spiffy graphics card, set the prefs to ensure the best performance, and swapped out connecting wirelessly to my speedy broadband internet for a hard wire connection.

Of course, lag is still an issue. Scenery rezzing slowly, chat lines appearing late and out of order, walking through jam...

I'm hearing rumours of strange things that can cause lag and I'm wondering...are they really true? Or are they just old wives tales? Can anyone say for certain if they DO really cause lag? If so, what kind of lag do they make and will the lag also effect other people in the area?

1. Wearing objects with bling and having the bling turned on.

2. Wearing scripted objects, e.g. swords, Neko ears that twitch.

3. Wearing high prim objects, e.g. hair that's made up of 65 prims.

4. Wearing flexi objects, e.g. skirts, hair

5. Wearing a large number of objects at once, e.g. a full outfit

6. Having a large number of items in your inventory.

Can anyone blow away the rumours and reveal the truth? Can we handle the truth? Is this already answered somewhere else?

1. Wearing objects with bling and having the bling turned on.
Script lag. Pretty minimal affect unless the scripts are written very poorly. Particle lag clientside only.

2. Wearing scripted objects, e.g. swords, Neko ears that twitch.
Script lag, affects other scripts in the area but pretty much nothing else.

3. Wearing high prim objects, e.g. hair that's made up of 65 prims.
Client side lag largely. The hair thing can be very bad with dozens of tiny tortured prims being endlessly redrawn in a hundred new flexi locations every second. I'd say this is the worst cause of "lag" in this list.

4. Wearing flexi objects, e.g. skirts, hair
Client side lag only, pretty minimal depending on how your flexi graphics options are set.

5. Wearing a large number of objects at once, e.g. a full outfit
Not very significant IMO.

6. Having a large number of items in your inventory.
Simply causes higher bandwidth use for the user, slower login times, etc. Not particularly significant (again IMO)

Actually, the most suspicious thing on your list for me is that you bought a new computer--are you running Vista? If so, remember that Vista does not currently support openGL very well. When I installed Vista on my laptop, I saw a thirty percent decrease in FPS in SL AFTER I'd tweaked every setting on Vista and SL I could. Before I tweaked those settings, the decrease was around 75%. (And I'm running First Look.) If you've not fiddled with the Vista settings, let us know and I'll post something here AFTER I've had some coffee

Kam

I was planning to go through and replace all the vendors with my store because I was told multiple times that script lag has a significant effect on fps. I'm using JEVN and am planning to switch to more efficient, simpler sell objects. Will this improve fps in my sim?

As has been explained on several threads in this forum, wearing objects with a large number of scripts can create significant lag in a sim (if not actually bring it to its knees).

Even a script that does nothing takes up resources just to run. So multiplying that script multiplies the use of resources. And residents may be unaware that a specific prim outfit or toy (like swords and personal shields) are script-heavy.

/327/4a/170299/1.html

/54/8e/145210/1.html

Kamael, on the Vista question, I'm running a Mac.

Just going to have a looksie through those threads, thanks for posting them Beebo!

Elanthius, when you say 'client' lag...does this just mean it will effect me and my viewer?

Networked vendors like an old JEVN will cause some lag, but unless you have several you're not likely to see an appreciable difference in performance when you replace them. And remember, it's not just your store that has scripts--you have to balance what you have against what everyone else on the sim has. When it comes to scripts, the big lag generators are:

1) Visitor Counters
2) Automatic Door openers
3) Any other script that "listens" on channel 0 (i.e., open chat) for an event that initiates the script's functionality. (e.g. A poseball script that makes the poseball disappear when the word "HIDE" is typed in open chat, or a script that "listens" for the approach of an avatar before activating (like an automatic door script))
4) Older networked scripts (like the old JEVN vendors)--iirc, the cutoff there is anything written before 1.7, roughly anything over a year old.
5) Ambient Sound Scripts
6) Dance floors

And again, no ONE of these will cause enough lag to be noticeable even in the statistics bar--it takes multiple instances to cause problems. I recently finished building a sim with over 40 ambient sound scripts on it, no problem--but if I threw another 40 or so listening scripts and several networked vendors out, I'd have lag.

Simply put, if you're being told that your store has script lag, look for things OTHER than the networked vendors (unless you have dozens of them). Also bear in mind than textures larger than 512x512, and the sheer volume of textures in a store can also contribute to lag. In my experience, textures are usually a bigger culprit than scripts in causing in-store lag.

Kam

The Mac Client is just a windows shell--it's not the best of the clients available (which is why when I bought my new computer, I went IBM compatible, despite my sister's rather long tirade to convince me otherwise).

And yes, client lag means that it only affects the end user--it has no effect on sim performance.

Kam

Yes. It also means people with faster computers (or lower settings) will have better performance. Basically it just means your computer has to work harder.

Is it fair to say that points 2 & 3 from the original list are the ones that I should be really concerned with when trying to maximise my (and other people's) SL experience?

2. Wearing scripted objects, e.g. swords, Neko ears that twitch.
3. Wearing high prim objects, e.g. hair that's made up of 65 prims.

It seems to me from reading the threads that Beebo posted, that wearing scripted objects (containing a large number of scripts) is the biggest issue here. One that is not just going to effect the person wearing the scripts, but potentially an entire sim.

However, I'm unsure whether this issue just effects other scripts in the sim? Or whether it will cause problems such as chat lag, jam, slow rezzing?

Well there's the thing. I do have a couple dozen networked vendors in my store. I don't use the multiple vendors (y'know, where there are arrows to scroll through the items), I use individual vendors where each vendor is one product. I'm not sure which version I'm using (definitely not over a year old though), but I know it listens for commands on open chat so that's not good. I'm gonna replace them all tonight with simple vend signs that have just one script and no listens.

Of the things you listed, high-prim hair that has lots of twisted toruses in it to make pretty ringlets and curls is the worst. And that DOES slow down everyone that can see you.

As a furry, I can also attest that werating a lot of high-prim attachments also causes client-side lag even if you do NOT have twisted toruses as part of it. I specificly have a Human form with non-prim hair for when I must wade through high-lag areas. I've gotten as much as a 2x improvement in my frame rate by dropping from a furry with prim hair to a human with non-prim hair.

I've run tests on the inventory issue, comparing an alt wearing exactly the same outfit and form as myself, where the only real difference was that the alt only had 500 or less items in inventory, while I had over 10,000 items in inventory. The alt could move around much faster and had a better frame rate.

Bling scripts and the like are mostly an issue when you have LOTS of people doing it at once, like in a club.

Well-writen scripted objects are not usually a problem. It's the ones that listen on open chat or that do active scanning that can cause lag. For example, if you had ears that twitch on their own, but don't listen for commands, that is pretty clean. If they listen for "/15 twitch", that is a non-zero listen, and a bit worse than no listens at all, but still OK. If they listen for "twitch" or "/twitch", they they actively filter through every word spoken around you, and that causes more lag. (This should not be confused with a loaded gesture, like typing "/blush" to play a blushing animation. That is a command and not a listen, and is processed differently.)

Wonder why no one has suggested that sl's computers/network are inadequate to run sl.

Well, not every word.. Or, maybe, there's another distinction between scripts that listen on open chat and do split everything said into words (bad) and ones that just check the start of what's said to see if it's something they're interested in (not as bad).


It's suggested pretty frequently. When I joined last year, people were constantly going on about how the SL architecture couldn't handle the then-current peak loads of about 10,000 online at once.

Well, there's little we can do about that. What we're discussing in this thread is things we can do to help things.

I'm running with a reasonably new (less than 1 year old) iMac, 1.5GB of RAM, and a beefy cable internet connection. the only prims I wear as a rule are prim/flexi hair and two (heavily scripted) HUD attachments. Inventory-wise, I try and keep undeer 2000 items.

In my brand new shiney class-5 island sim, I get hardly any lag, ever. When I go back to my former location on the mainland, it is a whole different story. There, it's slow, textures are slow to load, movement is slow, just general 'laggy' performance all round. The sad thing is, up until about 3 weeks ago, that mainland sim was great, and almost totally lag-free. Then something changed and it went downhill fast. (No casinos or other lag factories that I could find, either.) I won't complain though - it made it easier to decide to go the island route.

Also with regard to script lag, listeners on open chat (channel 0) contribute to lag only when there are lots of people around chatting. That's because they have to parse every line of type to see if it matches their commands. Also, the script language does not have a function to let you 'automatically' just parse only the beginning of what is said. It has to parse the entire line, and then break it into chunks before it can evaluate the first word. You simply can't listen for "hide*". Of course, when nobody is around chatting, the open listeners don't contribute to lag.

Another culprit is scripts using the sensor or sensorrepeat functions. If they're scanning at maximum range 10 times a second, that will contribute to the lag as well. The worst performing script on my island is one of these repeating sensors (and shame on me, it is one of my scripts), so I have to go and re-examine it to clean it up. It's a repeating scanner and an XML-RPC server. Not sure if that combo is the cause.

-Atashi

Untrue. Feel free to use something like this...

listen (integer channel, string name, key id, string message)
{
    integer index = llSubStringIndex (message, " ");
    if (index != -1)
    {
        string command = llToLower(llGetSubString (message, 0, index));
        if (command == "hide")
        .
        .
        .
    }
}

You can also set the listen to only respond when the owner speaks..

It's not that listening on channel 0 is bad by-definition - it's just bad when misused or when script writers don't do a little extra work to make it friendly..

Sindy in your example the listener is still open and still has to accept every single spoken line in chat. That is what I meant. The llListen command, in that example is not filtering the incoming chats. What you are doing in your example is checking every single chat message to see if it has a space in it, then if there is a space, you're breaking the first word out of the chat line and testing it to see if it is the word 'hide'. That is exactly what I referenced as having to parse every single line.

If you could set up your llListen to look for "hide" and "show" then the listen event would not have to receive and parse every single chat line. But you can't. You can set it to only 'hide' or only 'show' but not both.

And I fully agree with you about filtering on object owner. For every script I write, they are filtered for owner and I never use channel 0. For products where it is necessary to let non-owners interact, I use llDialog and have that working on a filtered non-open chat channel.

Unfortunately there are a lot of products out there that do use channel 0 and have no filters. That is what has the potential to contribute to lag.

-Atashi

My RL agency links to me in SL via either of 2 computers. One is a reasonably good Dell and the other is an old laptop.

The strange thing is that although the Dell handles SL much better than the laptop, which freezes up unless I stay in quiet areas, the laptop has the better framerate in these quiet areas.

Some client-side settings that can affect frame rate are draw distance and.. levels of detail? I forget the correct term I'm looking for.

But if the laptop has its settings configured for 'light use' and the desktop has its settings configured for 'power use' then it's possible the laptop is, at least in the quiet areas, runnig at a nice 'easy' pace and not trying to push itself, compared to a desktop that maybe is maxing out trying to run at the various limits.

I am of course speculating, but that would explain why a lower-powered machine could 'outperform' a higher-powered machine, in certain situations.

-Atashi

Actually, there's no llListen in the one I posted. I was only responding to your comment that the listen event "...has to parse the entire line, and then break it into chunks before it can evaluate the first word." What I posted was a way to not parse the entire line and not break the entire line into chunks.

I assumed you meant using llParseString2List which, especially since LL cranked up how big messages can be, isn't the best way to do things. It's slow and expensive and will likely break any script that's getting anywhere near being low on memory. I don't doubt that there are many scripts that do it anyway..

R - Rendering LAG -- Depends on user's computer and vid card
N - Network LAG -- high update and image download counts
S - Script LAG -- greedy LSL scripts
P - Physics LAG -- excessive collision checking and # of objects

CAPS - continuously generating lag
lowercase - generates a brief burst of lag during rez/tp/approach/login

(space) - negligible lag
+ - moderate lag
! - heavy lag

BlingBling: (R)
Twitchy Ears: ( S, N, if flexi: R )
Scripted Swords: depends on script!
High Prim hair: ( R+, n+ )
Flexi attachments: ( R+ )
Wearing many objects: ( R+, n+ )
Big Inventory ( n+ )

Visitor Counters (S+)
Automatic Door openers (depends) (S+)
Listeners on 0 (S+, or S! in chatty areas)
Older JEVN vendors: Can't say. Haven't seen code.
Ambient Sound Scripts: (depends) (r) to (R+, n!)
Dance Floors: (depends!) (R, N+, S+)-ish.

"Slideshow" viewers with lots of pics: (N!!, S, R) (I hate these!)

Vehicles: (S+, P!, N+, r)
Animation Overriders ( S+, n+, R+ )
Bullets, bouncing objects, and such: (P!, N!, R!)

One 'average' resident in a sim: (R, N, P)
40 'average' residents in a sim: (R!!, N!!, P!!, S)

More people means more lag. Think of it like this:

One person in a sim =
some network traffic to the sim, clicks, messages etc
sim checks physics and object interaction
sim sends one (or more) updates to the that one person.

Three people in a sim =
triple the clicks/messages etc
triple the physics checking and object interaction
NINE TIMES as many updates going to viewer clients (3 actors times 3 viewers)

40 people in a sim, "doing stuff" = 40 times the input and checking but
1600 times as many updates to send to viewer clients!! (40x40)

Granted most updates are pretty minor... but they add up quickly.

Question to you is have you updated your cpu and your graphic card? i have a Duel AMD and it ran sl slow as snot but once i updated it it runs faster than i ever thought.