[sldev] Script/Parcel/Memory Limits

[Imaze Rhiano]

Stickman kirjoitti:
>  I don't know what the official name is, but it's either Parcel
>  Limits, Script Limits, or Memory Limits.
>
>  It's been a while since I've heard any official word about it. Last I
>  did hear, LL was gathering statistics and didn't know exactly how
>  they were going to implement it, let alone what the limits would be.
>
>  Has LL made any decisions, and would they be willing to share them?
>  More minds on the issue can spot any holes or problems that could
>  arise, and there's still some rumbling panic among the masses that
>  can't be confirmed or quelled since we don't know how it'll work.
>
>  Many thanks,
>
>  Stickman _______________________________________________ Policies and
>  (un)subscribe information available here:
>  http://wiki.secondlife.com/wiki/SLDev Please read the policies before
>  posting to keep unmoderated posting privileges
>

Babbie's office hours and logs are best source of REAL information 
currently. I am just writing  good fictional
story here for you.

http://wiki.secondlife.com/wiki/User:Babbage_Linden
Tonight's office hour is last for this year - Babbie is going to have 
holiday :(

Current status:
- Functionality that allows monitor memory usage is ready in server.
- Currently what is missing is UI for client side.Should be done early 
2010 - thought most skeptics in audience
  agrees that this is really going to happen 2011 - just before world 
ends in year 2012.
- Parcel and avatar memory are going to be completely separated. If your 
avatar don't have enough memory
  for attachment that you are trying to rezz, then you will get error 
message and rezzing will fail - even if parcel
  have zillion bytes memory available. There is an exception here - in 
sandbox sims you can still rezz any object. (OH
  audience suggested that sandboxes would be renamed to "crashboxes" - 
Babbie didn't make any promises)
- You can show your OWN attachment memory usage, how much different 
attachments are using memory and
  probably other statistics. This means that you can't look your 
girlfriend attachments and see is she really using
  that XCite thingie that you bought for her - or is she cheating you 
and actually using that other manufacturer's thingie
  what was bought by her secret lover that you are not supposed to know.
- You can show your OWN PARCEL memory usage, how much different objects 
are using memory, other statistics
  and there is also going to be tools that help you to locate those 
scripts. You can't show avatar attachments memory
  usage in your parcel.
- You can show your OWN REGION - even if you don't own parcel in there 
(estate managers), memory usage,
   how much different objects are using memory, other statistics and 
there is also going to be tools that help you to locate
   those scripts. You can't show avatar attachments memory usage in your 
region.
- Parcel memory limitations are calculated from parcel's area. Initially 
things like double primitives doesn't effect to memory
   limitations. Babbie was hoping that someday region owners could 
effect to this - like create heavily scripted regions and
   lightly scripted regions.
- There is going to be at least half year warning period where residents 
can see their memory usages, but limits are not
   yet enforced.
- It is not technically feasible to do system that would separated "old" 
content from "new" content created after memory
   limit introduction - and would allow "old" content stil run without 
limits.
- Mono scripts are going to use memory that they are using - might be 
much less than 16Kb - LSL classics scripts are
  always using 16Kb.

According Babbie, there is at least one avatar that have 7612 scripts 
(using about 96Mb memory). And average user have
100 scripts. Highest script count what I have seen what was about 800 
scripts - and it is pretty normal that non-techie
person have 200-400 scripts. This kind awful statistics has been 
constant motivation about secondary discussion:
"Why people need so many scripts and what we can do for it so that there 
is no need for so many scripts?". This discussion
has lead several improvements that ARE COMING to scripts early 2010 - 
... err... someday...

PROBLEM: "There is too many scripts, I have GREAT IDEA! Let's limit 
script size to 16/64Kb! That would limit script usage,
RIGHT?!"
- or -
"Marketing person: WE NEED TO RELEASE SL NOW! Skip idea about that 
dynamic script memory thingie
whatever, we can't market such things anyway! Instead each script should 
have fixed amount of memory - DO IT NOW!"
RESULT: Scripters will split scripts to multiple scripts so that they 
can script larger scripts.
CAUSES: Multiple scripts will cause overhead because of communication 
mechanism and other thingies to get them work. Multiple
scripts are actually using much more memory than single script would use.
HOW-TO-FIX: Mono scripts are going to get function that allows them to 
allocate more memory for them self.

PROBLEM: "Whining customer: OMG COPYBOT! You can't allow scripts to get 
primitives parameters that would make copying
them too easy! LL: Don't worry, we allow scripts only get parameters 
same primitives where they reside. Bear hug?"
RESULT: Scripters will copy their scripts to every primitive in object 
(for example hair resizers).
CAUSES: Have you ever heard 255 primitive hair with 255 script resizer? 
I have .. I have several of those.
HOW-TO-FIX: llGetLinkedPrimitiveParams

PROBLEM: "Our servers can't handle load made by these functions if they 
are called repeately in loop and they also allow
griefers to grief hundreds person in second. We need to add artificial 
delays to these functions."
RESULT: Scripters will split scripts to multiple scripts so they can 
avoid delays and run scripts parallel.
CAUSES: Multiple scripts....Like hair resizers.
HOW-TO-FIX: llSetLinkedPrimitiveParamsNoDelay, maybe also other 
xxxNoDelay functions and different throttling method
for server that allows it to control load.

PROBLEM: "0MG! 1 can writ3 script! I am l33t n0w!"
RESULT: Badly scripted things like chickens. I hate chickens. Unless 
they come with some good wine.
CAUSES: Lag
HOW-TO-FIX: C# and other languages are coming, LL have already working 
prototype. Should be easier for creators identify
good from bad scripter.... Or maybe not...

PROBLEM: "OMG! I have great idea about HUD! We will built radar thingie 
and then will add hug thingie to it! Great? GUYS?!"
RESULT: Hundreds scripts are running in server that could be running 
client side only.
CAUSES: Lag
HOW-TO-FIX: Emerald viewer, client side radar, client side animations, 
client side scripting... someday

Babbie would really want to hear more reasons why people are using 
hundreds scripts. So if you have more reasons - please send them for
Babbie. So that his team can form strategy to overcome reasons behind it.

Anyway... you can stop whining now. Script limits are coming. There are 
no other options. Maybe even before world ends. You should start
thinking about those limits NOW! At least what you can do is to make 
your hairs and other objects copyable and allow customers to remove
scripts from them when they don't scripts anymore. You don't need to 
make your object modifiable - you just need to add option to your
scripts that removes scripts from primitives by calling 
"llRemoveInventory(llGetScriptName());". Some resizers have already this 
option.
Just don't be moron and disable this option because you think that your 
customers are too stupid.

... everything around this really leads to one real question:  "If a 
tree falls in the forest and no one is around to hear it does it make a 
sound?"
Or why there is script running when no one is around to see results? But 
that is architectural question that mortals can't comprehend.