Script lag in Neualtenburg

In [post=890625]this post[/post] on the "Nota Bene" Notary System thread, Zarf Vantongerloo said that
I'm curious what so many scripts are for and what they use up time for even when no one is about.

Off-hand, I can think of door scripts, but as far as I know, they only spring into action when touched and lie dormant otherwise. I know I've got a clock script I've been playing around with, but that's on a 51-second timer and even when it runs, I hope it doesn't consume too many resources.

Is it possible to identify CPU-heavy scripts, or do people just have to know what their scripts do? Is it even possible to identify the location of scripts whether they're running or not, or regardless of the CPU load they cause?

It surprised me to read this. I haven't noticed the sim being especially laggy.

Somehow, though, Zarf's complain worked wonderfully! I was at Neualtenburg yesterday for my irregular Church meeting events, and I noticed on the statistics that "Script Perf" was around 100,000, which is astonishingly good!

I'd like to chime in here as I am engaged these last few days in setting up my store again, but this time on the Platz and I have noticed killer lag.

I was going to wait a few days before complaining but then I saw this thread.

I find the textures today tend to load a bit faster than Nburg of old, but the lag on scripts is quite horrible and it *must* be because of scripts "using up the cycles" or however it is put.

I am currently selling a chair that uses a script to change colour when you click on it. I know the script is well written because it uses the simplest messaging between the prims of the chair and also because it was written by sky Honey who is an excellent scripter. This is a very very simple script that doesn't do anything fancy at all.

In any other sim you click on the chair and it changes colour, *maybe* in a high lag situation it takes a half a second to change. Over the last few days I have been checking on it periodically as I am building the store and it has been taking from 3 to 7 seconds to change colour! In SL that's an agony of waiting.

This is really really bad performance.

I am not tech savy enough to know what tools can be used or what can be done about it but its really bad for business if a store in the Platz can expect all their scripted items to run so slowly as to appear almost broken. I would suggest we find some way to address the issue.

A rule that no texture in Nburg can be above 512x512 in size would be a good start, but I dont even know where to begin to analyse the scripting issue.

I will ask sky Honey look at the door scripts just in case, but I dont think they are likely doing it.

I've been intending to scan the sim, looking for high-update scripts. It could be something as simple as an object a visitor left behind - number of scripts is never a really good indicator, whereas script time is. A small number of badly-written scripts can be the culprit.

Also, I've found even totally empty scripts seem to eat a little script time, so even a well-written script can be lagging things a little.

The next update with the enhanced estate tools will be a BIG help in debugging, since it adds a tool to find the top 10 most time-consuming scripts.

Alright - I'm taking bets as to the culprit for the script lag experienced in Neualtenburg. The pot is currently at 500 L$ donated by yours truly and anyone taking a shot as to the cause are welcome to join in. The outcome will be judged according to Aliasi's verdict and the winning bidder takes it all. If nobody guesses the outcome the proceeds will be donated to the MoCA.

I know absolutely next to nothing about scripting performance issues (yet) and the following list should therefore be construed as nothing but a clueless scripting newbies uninformed speculation intended simply as a source of inspiration for possible guesswork and debate:

1) The 200+ doorscripts in Neualtenburg are found to contain secret avatar key sniffers reporting to the SLHerald who stays with who among the notorious jet set society of Neualtenburg.

2) The Rathaus meeting room is found to contain a secret jedi mindtrick script, which introduces subliminal messages through a 1000fps changing texture convincing people to vote SDF and showing cutscenes from "The Shining" interchangeably.

3) Dnate is found to have left his Starax wand lying around with the trigger turned to the on-position. Neighbours relieved to find a natural cause for the mysterious flying saucer sightings every time they served tea.

4) A hidden trapdoor is found in Gwyneth's showroom leading to a basement containing some 500+ chicken hats attached to the similar number of manically dancing tiny avatars that mysteriously disappeared from the face of SL from one day to the other. "I only wanted to teach them proper manners" is raised as the defence.

5) A secret perpetual motion machine is uncovered deep in the dungeons of Keltrien's home. "With LSL the sky's really the only limit" is the quote given by the author when later that year he accepts an honorary fellowship with the Underground Society of Second Life Alchymists.

6) Farfletched admits to having installed a 2000+ lines scripted elevator for the MoCA incorporating elements of post-conceptualistic avantgardist art freeing architecture from the cubistic grid and in the process holding your coats in temporary storage for a modest 10 L$ charge.

My apologies for the crude attempt at humor in the above. I just wanted to do something different for my 10th anniversary post and since this was done on my lunchbreak I didn't have time for a rewriting of the constitution in Klingon..

After some initial exploration, definite numbers will be impossible until after 1.9, but I think we're suffering "the death of a thousand paper cuts". we have 3.4k scripts in-sim, which is a bit on the high side.

One thing you can do to help is, if you've got a script that sets a particle system or texture animation, you can delete it or click off the "running" checkbox if that particle system or animation is never further updated. Even when it isn't active, such a script takes up a small bit of script time as the sim as the scheduler checks on it, or so I understand from experiments I've done.

Also, the gas lamps and snow, while lovely, are numerous... individually they aren't bad at all, but it might be nice to reduce the number slightly to see if they help, since both spit out fairly frequent updates (although updates are a middling poor statistic to use at best).

Interesting about the particle scripts since conventional wisdom is that particles cause client side lag only and only on slower computers, but what you say makes a more sense to me. Am I right in thinking that a script that generates a particle system should basically "turn itself off" after it sets the initial particle stream then?

Since it's already past the lunar new year, maybe we could switch the sim over to spring and get rid of the snow altogether. If there is a difference it could be easily seen.

Conventional wisdom is mostly correct; however, a bunch of my friends and myself pitched into to get a private sim, and one of them decided to experiement before we began building. She rezzed 100-something empty scripts (nothing but a blank state_entry()) and we wound up having 2-3ms of script time being used in an otherwise empty sim.

Anyway, I don't think the script can turn itself off, but YOU can. Remember, particle systems set an attribute of the prim; once you've enabled it you can delete or unchecked the "Running" box without ill effect.

Something like Field of Dreams is a little different since the particle system is constantly being randomized, but I'm playing with the ones I use to help a little.

llSetScriptState(llGetScriptName(), FALSE);

Durrrrr. I is SMRT.

I thought the Nota Bene devices in the Rauhaus contain a total of 2,000 lines of code (2 kloc).

Excuse me if I'm being blunt here but I simply do not understand what is the point of that statement?

FWIW in my observation there was no platz-lag prior to Nota Bene being installed.

Well, if there is 3.4k of scripting in the Sim, and there is say (per the NB creator), 2000 lines of code in the device, it's actually more like 3.4k of script code in the sim and 20+k of script code in the device. LSL is an interpreted scripting language right?

Hard to say what the notary script resource usage is though.
Maybe that thing needs to be "turned on" right before it's used and "turned off" right after.

I think the platz should really focus on scripts that are for the commercial benefit. Even if it means removing doors. Lag is a business killer.

I could be wrong, but I don't think lag is caused by the size of the script only the resources it consumes or bad timers and the like. Are you saying that the entire script is being loaded and sitting in a limited pool of memory? I thought the "limited pool" was more akin to execution cycles or CPU time than it was to a memory space that the code had to be loaded into.

Also there has always been some kind of lag all over Nburg. Even when I had my store on Sudanestrasse, clicking on the door sometimes took a second to register. The front door on my new store on the Platz is now taking maybe a count of one or two seconds to register (a bit longer).

It is a killer for business though. If I have time, I will take my chairs around to different parts of the sim and see if they change faster or slower depending on distance from the platz.

I don't actually know if script size is correlated to lag, but anecdotal evidence of experiments by others found that 100 objects with just state_default{}slowed their sim considerably. It's not just the lag, it's what happens when impatient clients hit things multiple times and suddenly buy 3 items from a vendor instead of 1. Ouch! Talk about an annoyed customer...

Pelanor, things don't work that way. And you don't have to say some mysterious "others", I'm right here!

ALL scripts, big, small, or middling, have the same (rather small) amount of memory dedicated to them; this is one reason large projects often have to be split up into multiple scripts. However, those scripts are usually communicating through link messages, and thus not, in itself, a problem.

Similarly, I've noticed some sim lag since before Nota Bene. NB's installation obviously wouldn't help matters, but this doesn't really mean NB is the main culprit.

AFAIK, it's a bit like Java -- the source code is compiled to some sort of byte code when you save the script, which is then interpreted at run-time.

Does the Guild have any rules or guidelines on lag?

As I said previously, I would strongly support outlawing all textures above 512x512 as it's clear that this is a problem and similarly clear that one should (pretty much) never need to use anything bigger but I have no idea about scripting lag really.

If the Guild was to publish a written "positive" guideline as to what things to avoid and if we all agreed to abide by it, it might keep us from having to act like cops and go around trying to find lag "offenders."

I'm not the right person to answer this so pardon me if I'm wrong - what I could find on the topic was the following excerpt from the covenant:





I agree and I think it should be part of the covenant if we can decide on a procedure to get it amended (of course there may already exist a procedure that I'm simply not aware of). If we do decide to amend the covenant though, I think we might as well take into consideration some of the other issues that Dianne and have I raised in the thread on this.



Perhaps this is something that could be thought into the concept of the proposed Warenhaus?

Thanks for posting that.
*smacks forehead*

I totally missed it even though I have the Covenant printed out and lying on my desk this morning.

No problem. Always glad to help! Although as Frank Lardner may - with the help of Steven Weber - have indirectly pointed out, my motivation for helping may not be as altruistic as I myself believe.

I'm wondering if any of you know if resources for optimizing scripts in terms of reducing resource consumption and speeding up runtime? Are there any good "under the hood" sources for LSL? Thanks! Maybe I'll go ask this on the scripting forum as well.

That's a good idea -- will help those who aren't experienced scripters, for example.

I believe I've read that, for example, llSensorRepeat and llListen on channel 0 are prime lag candidates, but I don't know what LSL methods, in general, tend to be laggy and which are harmless. It would be nice to have a reference, assigning rough numbers to various methods so that you can tell what to avoid.