Project Decision to Reduce Lag (Question and Advice request)

[Geldsbard Freck]

Hi all,

This is my first post but I've been building and scripting in SL since '08. I also program in iBasic which is a compiled language with OOP structure and similar to C. .... bla bla bla bla 

end Intro

Project Explination (limited info)

My current project is a controller for linked objects. The controller "panel" has linked buttons and control sliders that control linked objects at a distance from the controller. It controls these objects attributes such as color, rotation, glow, etc. Originally I went with linked messaging: The panel itself receives messages from the buttons and sliders then sends messages to the external objects such as rotation values, color,  on/off, etc according to the data received from the buttons and controls. The objects receive these messages and act accordingly.

At this point I have 9 buttons and 12 slider controls, the controlling panel, and 23 controlled objects (some objects are "twins" and act on the same commands from the controller). This makes a total (so far) of 46 running scripts in a single (grouped) object! The whole system is expandable to the customer's requirements and could double or even triple the number of scripts. The largest script is the main controller in the panel. the buttons' scripts are small - 6 lines, but the sliders' script is a bit more complex with touch locating, texture manipulation and percentage calculations.

I think I've already answered my own question, but for the purpose of reducing lag; I'm thinking that llSetLinkedParamsFast() could be used rather than linked messaging, removing the need to put scripts in the controlled objects. The buttons could be done the same way with a touch face location on the main panel and their display (on/off - green glow/dark green) could also be performed by the main panel with SetLinkedParamsFast().

If done this way, the whole thing will run on one script, but the script for the main panel will be necessarily huge ... BUT it will be idle 99% of the time, acting only when touched. (no timer states, no listening, ect)

Is it less laggy to have 50 really tiny scripts at idle or one big huge script (mostly) at idle?

I can code it either way so my concern here is to find the least resource hungry method to achieve my goal. If idle scripts have little impact on the sim or do they eat up resources reguardless of size.

Any thoughts on the matter is appreciated - thanks.

[Qie Niangao]

A single script is better, if you can get it to work.

I'm a little confused, though, about the application. Link messages and llSLPPF only work for prims in the same linkset,  but you refer to "controlled objects"... so unless those "objects" are really just prims in one big linked-together object, you'll be needing interobject communication between the panel and the separate objects it controls. Because you say you're currently using link messages, I suppose these really are all linked together, but just making sure.

Every script uses a tiny slice of processor time in the scheduler, even if completely idle. At this scale, it's not a huge amount to worry about, but there are other considerations, too. Sending and processing link messages has some overhead, all of which can be avoided by keeping the code in a single script. Indeed, the code for sending and processing link messages uses some memory, too. Also, every script incurs some memory overhead just to exist, so fewer is better that way, too.

[Rolig Loon]

Reduce the number of scripts. Whether it's active or idle, a Mono-compiled script has been assigned 64K of memory, so your 50 scripts are being allocated 3.2M of server memory vs. the 64K that one script does.  Each of those individual scripts are also using 0.001 to 0.003msec of script time while idle, so adding up to 0.15msec to the server load.  All of that is aside from the added efficiency in the script itself when you can do away with a lot of duplicated code.  Besides, using llDetectedTouch* functions and textured buttons is a whole lot less clunky-looking than a pile of prim buttons.  :smileywink:

[Qie Niangao]

---

Whether it's active or idle, a Mono-compiled script has been assigned 64K of memory, so your 50 scripts are being allocated 3.2M of server memory vs. the 64K that one script does.  

---

Not to quibble over details because the conclusion is absolutely valid: each script uses some memory overhead just to exist, but Mono scripts don't really use 64KB, nor any lower limit that one may set.  The 64KB "allocation" is really a quota--the limit to which the script is allowed to grow, but the script will only use what it needs. That's why there's no actual memory benefit to setting a lower limit, but doing so makes external memory reporting more accurately reflect how large the script can grow--at least until it sets itself a higher limit.

[Rolig Loon]

That's true.  I was trying to be careful about language without making it sound too arcane.  The point is that even if your Mono-compiled script doesn't actually use the 64K of memory allocated to it, that memory is reserved for its use from the total script memory potentially available in the sim.  If you can squish several scripts into one, saving much of that reserved memory, you are a better steward of sim resources.

[Qie Niangao]

I hate to further belabor such a minor point, but a script's memory limit is not actually reserved for its use; what memory it's not currently using is available to other scripts. The limit is really more like an accounting quota. Still, the conclusion is completely correct: combining multiple scripts into one will save sim resources, including memory.

[Nova Convair]

I see: "linked buttons and sliders" that means: you need only ONE script to control all buttons and sliders. Every touch goes to the root and there you check link number, face and position on the face that was clicked.

For the controlled objects: if they are linked too, you still need one script, if they are unlinked you need ONE script per object to receive messages and execute commands.

 

[Ela Talaj]

Have you ever noticed that in some LSL documentation scripts are called "tasks". That is actually a correct programming term for it. Indeed each one is a little task telling the server how to change the rendering of an object; it has its start, its end, its rest periods when it waits for something to happen, etc. So what starts the start? What happens when it ends? what tells it that what it was waiting for did happen? All that of course comes from the operating system, so each script-task uses some OS resources. The more scripts the more resources used.So generally less scripts is better.

However there are no rules without exceptions. If you are able to write a script performing a certain generic function which can be used in many applications then you are much better off making a specific module and doing application-specific stuff in another module. Would save you a lot of time reusing instead of rewriting even if you lose a few hundred milliseconds of CPU time. This is called "encapsulation" and in the real world where the hardware is cheap but software costs a lot of money it is the king.

[Geldsbard Freck]

Please forgive my ambiguity, I am guarding my idea as best I can because as far as my research can find, no one has tried this in SL yet. It will mean a limited number of sales since it's a highly specialized system.

To answer some of the questions:

It is all linked objects, the control panel itself being the parent or root object.

llSetLinkedParamsFast() could be used to manipulate the controlled objects.

My use of the term "external objects" simply means that although linked, their location is typically some distance away from the parent prim.

These answers have been very helpful, thanks. I believe that I am going to build two systems - one in modular form that a client can build a system as large as they need without technical intervention and the other would be a (sort of) custom build. But either way, both systems will operate on a single script.