It would be nice if everything were free, too. The issue is memory *allocation*. If a script only uses 16K but is allocated 64K, that 64K counts against the server's actual memory allocation limit.
So, cool, wouldn't it be nice to only allocate what is actually requested? Well that implies rewriting a lot of code to use memory differently, and requires frequent reallocation of memory (as the needs grow or shrink). There is a real cost to this, in terms of programming effort and in terms of runtime costs. Until now, script memory has seemed to be a free lunch. Well, the free lunch is over, and we'll have to deal with it. I won't believe that it's feasible to simply "report the actual memory used" until someone who really understands Mono memory allocation and our scripting language's arrays (the main memory users) says that there actually is a feasible solution along these lines. Change causes upset. This will be an issue. IMHO, though, failing to address the problem would be worse. Regards Jeff On Sun, Mar 7, 2010 at 6:20 AM, Marine Kelley <marinekel...@gmail.com> wrote: > Well we have two mutually exclusive solutions here. > > Either Mono scripts are given a hard memory limit that we (the scripters) > can change within the scripts, with all the overhead work that it implies > (i.e. modifying hundreds of scripts before issuing an update, and having to > know upfront how much memory will be taken exactly), which means that in > regards to the scripts memory usage UI, the script will use exactly as much > as the limit it has requested, no matter whether it really uses it or not. > This gives wasted memory and false information. > > Or, Mono scripts are given a hard memory limit that we cannot change, and > they report exactly as many bytes as they use at any time. But we shouldn't > be able to change the limit ourselves, because it wouldn't make sense to do > so, it would only be restraining ourselves if we set less than 64k, and > wasting memory space if we set more than 64k. > > In both cases, the question of whether the script crashes when reaching the > limit or not is not related. > > I seriously, and I mean seriously, think that choosing the first option is > going to hurt the established scripters very badly, and therefore the grid > as a whole. To me scripts should report exactly as much memory as they use, > not more, and should not require the scripters to modify them to report > something that could be computed by the sims more accurately anyway. > > Of course it is tempting to tell the scripters "you can now decide how much > memory to allow, and that way you are certain it will report the amount you > have set", as much as it is tempting to shift the workload of allocating > script memory onto the scripters since LL can't seem do it. > > Remember, we are now going to have limits on a service that didn't have them > before. For the same price. All in the sake of stabilizing the grid. Ok for > me. This will already hurt scripters who will have to adapt bad scripts. But > now we are told we are going to also adapt good scripts as well ! I repeat, > this is unacceptable. > > Marine > > > On 7 March 2010 03:02, Frans <mrfr...@gmail.com> wrote: >> >> As for the dynamic vs fixed memory usage. Of course it would make sense to >> have dynamic memory usage, but I haven't seen a response yet on how to solve >> the problem that Kelly described, about scripts suddenly running out of >> available memory to use, when they fill up lists with info, etc. And break >> because of it. Or is this considered not to be a big problem? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
