few large scripts vs many small scripts?

So, if I have an object that has (eg) 20 different functions, is it better to have 1 large script, 20 small scripts, or somewhere in between?

What's the pro's & cons for lag, script performance and memory usage? And also, scripts being in linked objects, the advantages or disadvantages of communication across linked prims and whether to put as many scripts as possible in the root or the children. I don't want to know how to do it, I'm aware of that, I just want to know efficiency wise which is the best way to go.

My preference is probably in between, with say 5 - 6 scripts and 3-4 functions each.

From my simple point of view, more atomic scripts are easier to code and maintain, with the only problem being shared values need message passing, so try and group functions using shared values in one script.

I'd like to hear of anyone's experiences one way or the other, so I know the best approach to take. Thanks.

llMessageLinked() is almost instantaneous so communication is rarely an issue, just make sure that commands are passed via the number parameter, as number comparisons are MUCH quicker than string or key based ones.
Then place data in the string message.

However, it really depends what you're doing, in some cases you HAVE to use several scripts, for example if you have high memory requirements, or you need to do something with individual prims.

But sometimes having just one script is much easier, especially for the end user. If you go that route then you can still group functions together into groups to make it fairly easy to maintain.

I guess really it depends on personal preference, object oriented programming and abstraction are often wasteful ways to do things, but if you value maintainabiltiy and code correctness then they're often the best. Especially as having individual scripts doing specific tasks is easier to test (e.g you test the HTTP communications script before you test the main script, so bugs can be isolated to one or the other when they arise).

One thing to be wary of though is that if you use linked messages, and one script has less memory than others, than large messages can cause problems, and may cause stack/heap collisions in the lower-memory script. e.g if one has 4kb memory free, and another has 1kb, and they both receive a 2kb string, one will suffer problems. Curiously not always stack/heap collisions though in my tests.

Also, clever use of these separated scripts can sometimes be faster overall, you have to watch for the order of the messages though, sometimes two similar speed scripts may execute in the wrong order from what you expect their replies to come in.
The order of link-messages, and knowing WHEN to deal with X response is often very tricky, so too much abstraction can be bad here. For example, don't try to put all string manipulation into one script as passing them around that way is often much worse than having the functions in your main script (assuming you can fit them).

A good model could be (for example):
Main Script
- Data container (big list)
- HTTP Comms (deals with sending messages to another server)
- Instant Messager (sends instant messages to avoid the delay in your main script)
- Emailer (same as above)
- Notecard Reader (reads in your initial settings for you, since this is a one time only thing usually).

The simplest answer is that if you don't need multiple threads, and you don't run out of memory, then cram it into one script. It's ugly, and a horrible coding style, but a script just by existing locks up as much memory as it's allowed, and gets pinged now and then. Plus using one script locks you into a sort of maximum execution speed. That may sound bad, but if it doesn't cause a problem with what you're trying to do, live with it, it's polite.

I'm pretty sure it's not all going to fit in one.

I guess it was more a question of whether to keep cramming in 1 script till it overflows, then another until it overflows etc, or whether to not worry about cramming and just split everything up into managable proportions.

IS there a way to tell how close a script is coming to it's memory limits? I've seen people refer to their free memory, bit so far I've missed where to get that info.

Thanks for the replies.

llGetFreeMemory()

If you know you are going to need more than 2 scripts then i would approach it from the other side and put your functions in as many scripts as you need, get them working correctly, then if you feel you DO have a few small scripts that could be reconciled into 1 larger then do that.

There is nothing worse than cramming it all into a tightly packed script then realizing you left out a particular IF clause or need to add a another message, and finding that you have to rework the whole script just to squeeze it in.

That's a good idea Ariana, as since I work out the mesage passing for one script, it's pretty much the same for all of them, and combining again shouldn't involve too much recoding.

And thanks for the llGetFreeMemory() Rodrick. I've been using an old document as a quick reference to LSL commands, and I think it's missing about 50% of them. I'm trying to get a printable version of the Wiki so I can read up on all the extra's I'm missing.

I tend to prefer the "cram it all in" approach for a number of reasons.

One, I find it easier to debug than smaller parts. I write in quite a modular style, get one bit running, checked, then write the next bit. I also find following the logic flow easier that way.

Two, it's often more secure - quite a few of the things I sell people can add scripts to (it's modifiable) and a "link message" snooper is easy to write, so you end up encrypting link messages and blah... silliness ensues.

Three, if I must split stuff up (and I do and have done this too), I find it's *easier* when I've got the lot done. Because I've scripted it in chunks I find it easier to look back and say "oh, this chunk can come out" because I'm aware of the interactions between chunks in a way I'm just not from the planning stages.