Babbage finally blogs about script limits

By adding small functions and seeing the results of llGetFreeMemory() go down by 512 bytes for each.

Since I had to add a call from a state, but the change was always 512, I get the impression that states are also aligned. (Worse yet, even the end of the last state ....)

Oh. Duh.

/me claims immunity protection under the BrainDeadByFriday law.

Assume you have a script that consists of 5 global integers, 3 functions f1, f2 and f3 which are 200, 520 and 1200 bytes of code respectively (event handlers count as functions).

What the compiler ends up doing is:
20 bytes of integers
492 bytes of data padding
f1 goes here and is 200 bytes
312 bytes of NOOP padding here
f2 goes here and is 520 bytes
504 bytes of NOOP padding here
f3 goes here and is 1200 bytes
336 bytes of NOOP padding here

Total code size: 3,072 bytes
Useful code size: 1,920 bytes
Wasted: 36.5%

For f2 you'd want to try and rearrange or rewrite its code to shave off 8 bytes which would give you an extra 512 bytes of memory.
If f3 calls f1 (and nothing else does) then you might as well inline it and save yourself another 512 bytes of memory.
Etc.

It also means that you might as well use up 123 more global integer variables without taking up more script memory (or get a string of 492 bytes for "free". Or on the flip side that extra global variable you add (or those few extra characters you added to a global string) may cost you 512 bytes if it creates a new data segment.

I now know that the LL developers are more dense than I ever suspected.

Worse. It means we should favor in-line coding instead of calling small user-defined functions. Not that LSL provides any macro functionality to make in-line coding manageable. On the other hand, there's no law against running code through a preprocessor offline to generate LSL .

It's even worse than that...

You may end up saving that 512 bytes if you're lucky, but if you're unlucky and the inlining pushes more than one function over into a new 512 byte boundary then you've just made things worse (memory wise) .

(Edited to add: I IM'ed Strife about the 512 byte alignment for functions and data segments somewhere late 2008 I think to add it to the Wiki but if it's not there it would be helpful if someone added it if it's not common knowledge)

Looking on the bright side, the in-line code would run a smidgen faster without all the routine calls and parameter passing.
Over the holidays I'm going make some time to play with
1) Eclipse
2) Exporting processing from SL to my own server

Havoc 4 raised the build height. You can also build lower and then raise the build, but is a real pain to work that way.

Trya some nice spaghetti, eh? You likea the sauce?

Maybe we should have an obfuscated mono contest. Or I could give lessons in how to optimize code to the level of driving anyone insane who tries to understand it.

Bax boots are scripted like this.

The difference between heavily scripted Bax boots though and heavily scripted Stiletto Moody's is that you can actually teleport wearing Bax boots.

I had spaghetti for dinner today... how did you know?

*Runs around yelling "Disclosure! Disclosure!" *

(I didn't want the function names to distract from the rest, next time I'll use foo() and bar() )

You can, though I think you're best advised to use the selective "remove scripts" feature when you've finished resizing them. It's selective in that you can -- for example -- take out the resizing scripts but leave intact the ones to recolour the details of your boots or put the tops up and down.

You can also, which I think is a really clever idea of Bax, have the boot chat the size settings after the helpful assistant (or you, of course) has adjusted them to the right size, notecard them and then just "say" these to another pair. Since the boots are copy, this makes it really simple to keep a pristine backup copy in your inventory and then make several fitted copies, differently styled, and take out all the scripts from these.

This is just as well, to my mind, since recently I'd just finished styling some of my lovely new boots, realised I was late for a meeting and TP-d there without bothering either to change my boots or remove the scripts.

And when I arrived everyone shouted at me for freezing the sim for about 4 seconds.

Yes this is useful and I easily transferred settings from one pair of boots to a different colour. While Bax lets you selectively remove scripts, Stiletto Moody's do not give you that option and thus why when your shoes have 300 or so mono compiled scripts that I cannot remove is the reason I cannot teleport wearing them.

Oh, just like to say thanks for very insightful information in this thread. I've just saved some memory in a full script from the information here.

No need. You've already driven me insane.

absolutely, people are always missing that second L.

grins

Agreed, and that's been coming up at the office hour discussions, so expect tools in that area that everyone, not just estate managers will be able to have.


Listening on channel 0 is ok as long as you don't keep the listen open all the time. I tend to code such that when the function is activated (usually via a touch) the listen is opened, and then once the action is taken, the listen is removed.



Heh, that says it all, if you've done assembly coding then I'm sure you're an efficient LSL coder

I dont see where they've failed in this respect. As time has moved on, they've upgraded the hardware, added memory, and done other things to improve efficiency on their end to reduce costs. I'm not sure what you expect from them as replacing all that hardware is difficult. They have to sell off current hardware then replace that with newer hardware, which they've done. Servers have 4 gig, which is maxed out for most computers, so I don't quite see where the problem is in that area.

Script limits are about prudent usage on the user end. Regardless of how much money is poured into upgrading hardware, without limits, resources will continue to be consumed to the maximum of the hardware limits. Welfare is a perfect example. people on welfare consume 100 percent of what they're given without a thought of where those resources come from. It's the same thing here. The line has to be drawn in the sand somewhere. To be honest, 3 years ago when I first got involved with SL, I was surprised to see that there were no limitations in place back then. Sure, they were smaller with far less residents, but still, I saw this day coming my first week in SL.

I have to completely disagree. Script limits are not about LL being mean, or being cheap. They're about causing the residents and content creators specifically to be prudent with script usage. The free ride is over. SL has grown too big for the free-for-all that's been going on since day one to continue.

AGAIN, I personally don't see this being as big a deal as everyone is making it out to be. There well be a long transitional period where limits are not enforced so that residents can get their usage in line/creators can recode products, and the day that limits are imposed will likely generate nothing more than a few yawns.

Actually that example was microcoding so I was at the level right below assembly.

The level right below assembly is machine code, which is dealing with the machine code itself rather than assembly mnemonics. Microprogrammes are those that are built into microprocessors, so it's not clear what you mean by microcoding.

That's what it was quite some time ago but I'm sure someone will tell me how it's all changed since then

LOL - I was thinking that it indicated she lives in a closet and folks toss in twinkies now and then . I absolutely hated assembler, though it was the only programming language back then that gave me any trouble.

I was not too wild about assembly, too high-level. Optimizing it at the microcode level on the other hand ....

Sure, which is why I said it needs to be a two pronged approach, upgrading hardware alone means we'll just end up back in the same situation in no time at all. They need to do both.



I keep seeing things like this, Xstreet can't scale, SL can't scale, it's all negative vibes about scalability. Being prudent is one thing, but by LL's own admission this is going to only affect 5% of regions, there will be little noticeable performance increase on the back of script limits. Which regions is it likely to hit? Well possibly sandboxes and regions where people go to learn things. Which isn't a positive step at all. Busy and popular places, those are where the issues are likely to arise.



Yes it is encouraging that it will be a long drawn out process, it needs to be. They get this wrong and they are going to cause one hell of a hoopla.

This is one of my pet peeves, too.

Q. How can you tell when a Linden is lying?
A. When they use the word "unscalable."

(The usual answer for lawyers doesn't apply because Lindens' lips are moving only when they're using voice gestures.)

Philosophically, I'm not sure what it means, which resources are allocated and which are handled as commons. Since forever, prims have been allocated: you get to rez only so many per sq.m. Avatars remain commons: however many can fit in a sim can all crowd into one tiny parcel, leaving residents of the rest of the sim unable to get home. Scripts are now moving from the latter category to the former. What's next to make that transition, if anything?

As the Mainland "estate manager", LL has a special challenge, but this particular change in scripts is at least as important to Estate owners and their tenants as to Mainlanders. Although Estates could see some of what scripts were doing to them, and might be able to reduce the damage caused by rezzed-on-parcel scripts, they were helpless when Suzy Blingtard and her amazing scripted attachments TP'd into a store and the whole sim stopped for a few seconds.

I'm curious what other resources Estates would want LL to equip them to manage. (I think I'd want the ability to allocate texture and sculptmap resolutions, but I spend 90% of my time on the Mainland.)

I am guessing partices. There is a fixed limit of how many you can have in a sim but it is a free-for-all to use them. Most people use only a few (fireworks, leaves, butterflies, weather, etc), but some people do things like make particle towers thousands of meters tall on a small plot.

It is mostly a client-side issue, but once a sim uses it's allocation nobody else in the sim can create more.