[sldev] Static universal memory limits are operationally non-scalable
Marine Kelley
marinekelley at gmail.com
Sat Dec 19 04:21:25 PST 2009
I agree that it makes it more difficult and more expensive to scale the
system, but when was the last time when LL added available memory to scripts
? When they introduced Mono. I don't see that happening very often, and the
cost of introducing Mono was certainly dwarfing the cost of upgrading every
server software, which they do on a weekly basis nowadays.
Besides, what's the point of making the software scalable if nobody's going
to use its capabilities anyway ? That's what happens when the users lose
faith in their tool, they just walk away.
Let me give you a little parallel with a very concrete example. Suppose you
buy a tool for a very specific task. Let's say a frying pan. You are given
information about the limits of that pan upfront. Don't heat beyond X
degrees or it will deform. That limit is hard, and you can rely on it, your
pan has been proven to take it up to X degrees, and is not guaranteed to
work well over it. If you need to go beyond X degrees, you buy another, more
sturdy (and heavy) frying pan, but you don't try your luck with the first
one. Is that data ever going to change ? No. The first frying pan takes it
up to X, and that's it. Each task requires the adapted tool.
Same for the scripts. If you really need lots of memory for one script, you
reserve it upfront, at the very beginning, either by choosing the type of
script (LSL or Mono for the time being, but LSL will be left aside
eventually), or by calling functions. You do NOT presume that your script is
clever enough to restrict itself when memory runs short, it is not. And it
will break like your frying pan.
Marine
2009/12/19 Carlo Wood <carlo at alinoe.com>
> On Sat, Dec 19, 2009 at 01:07:01PM +0100, Carlo Wood wrote:
> > "64 kilobytes ought to be enough for anybody" -- Bill Gates
>
> I guess it was 640 kilobytes :p
>
> --
> Carlo Wood <carlo at alinoe.com>
> _______________________________________________
> 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/5a0ef4fd/attachment.htm
More information about the SLDev
mailing list