[sldev] Static universal memory limits are operationally non-scalable

Marine Kelley marinekelley at gmail.com
Sat Dec 19 03:59:10 PST 2009


In that case you'll start to see scripts crash randomly as soon as they hit
the hard limit (which is prone to move unpredictably, according to the
number of avatars in the sim and such), scripters will lose faith in the
scripting language and stop scripting at all, and eventually leave.

That, or they will make sure their scripts never reach the minimum amount of
memory they are sure to have at hand, making it de-facto the official fixed
limit. Worst case scenario.

Or, they will have to call functions to check whether they have enough
memory to allocate whatever data they need at any given time, turning the
scripts into unmaintainable bloatware. And adding to the bytecode size at
the same time, making the scripts get dangerously closer to the memory
limits without even writing one more line of useful code. Only scaffolding.
Not to mention that we can allocate memory, but not deallocate. An empty
string takes more memory than no string at all.

Scripts die when they run out of memory, that is a fact. As long as that
fact is true, a script must never enter that case, no matter what. Making
the limits dynamic essentially tells the scripters "you have X MB of memory
available, but not all the time, up to you to make your scripts consume less
memory when able". Right.

Marine

PS : Sorry for the double mail Morgaine, I once again pressed the wrong
button.


2009/12/19 Morgaine <morgaine.dinova at googlemail.com>

> Defining a single memory limit that applies universally regardless of the
> equipment on which it is running is operationally non-scalable.
>
> A single universal limit implies that the limit cannot be raised as old
> equipment is replaced with new, until such a moment when *ALL* the old
> equipment has been replaced with upgraded equipment.  As the equipment
> population N increases and the interval between whole-population upgrades
> increases with it, the utilization factor of newly installed resources drops
> to a worst case of 1/N, and an average of N/2N = 1/2 over the upgrade cycle.
>
> What this means for the provider is that effective resource costs are
> double the actual resource costs because 1/2 of resource upgrades are
> wasted.  What it means for the consumer is that available resources lag
> installed resources for an ever-lengthening period of time as the system
> grows.
>
> The above applies to all resource types that improve as technology
> improves, not just the memory limits that we are discussing here.
>
> Static resource allocation should almost never be used for delivery of
> dynamic resources, as a matter of principle, because the resulting resource
> utilization is so poor.
>
> Morgaine.
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/e96a4edd/attachment.htm 


More information about the SLDev mailing list