|
Deanfred Brandeis
one who programs
Join date: 20 Aug 2006
Posts: 20
|
03-19-2007 14:07
The unofficial LSL wiki (lslwiki.net) still says that llGetFreeMemory is broken, but the comments are rather old, and several releases of both the server and viewer have been released since then: From: someone As of SL 1.10.6 (July 16, 2006), this function remains broken! llGetFreeMemory will not take into account memory that has been freed, which can result in far less free memory reported than actually exists. What it will report is the historic free memory--the smallest free memory up until that point. So, in theory, your script could have nearly 16kb free, but report only several bytes free. Depending on what you need, this isn't necessarily a bad thing, but if you're relying upon llGetFreeMemory to know when a script is "full", you may run into some problems. The new official wiki, of course, says nothing useful beyond what the function does. Does anyone have any word on whether this function is working properly again?
|
|
Deanna Trollop
BZ Enterprises
Join date: 30 Jan 2006
Posts: 671
|
03-19-2007 14:49
default { state_entry() { llOwnerSay( (string)llGetFreeMemory() ); list TestList = [ "This", "Eats", "Up", "Memory" ]; llOwnerSay( (string)llGetFreeMemory() );
TestList = []; // This should FREE memory llOwnerSay( (string)llGetFreeMemory() ); } }
Output: Object: 16032 Object: 15947 Object: 15934
Short answer: Nope. (Which is why I'm going through all sorts of codespace, memory and CPU-cycle -wasting gymnastics on a project involving dynamic data storage to ensure I don't get stack-heap collisions  )
|
|
Deanfred Brandeis
one who programs
Join date: 20 Aug 2006
Posts: 20
|
03-20-2007 10:16
From: Deanna Trollop Short answer: Nope. I've been doing some experimentation in a script I'm writing that does a lot of simple list manipulation (adding, deleting, replacing), and I've noticed that if llGetFreeMemory() is still broken, it's not broken in precisely the way the comment on lslwiki.net says it is. In my script, free memory does get larger, but only some of the time you would expect it to. For example, if I delete an element from a list, immediately after doing that, llGetFreeMemory() may report no change or even a decrease in free memory, but only a few lines later, it will report a small increase in memory. This leads me to believe that garbage collection might not be happening properly when using some of the by-value list copy functions (llListReplaceList(), llListReplaceList(), llListDeleteSubList(), etc.), such that one of the copies of the list is hanging around somewhere in memory and not getting deleted when it should--perhaps never getting deleted entirely. If so, this situation is even worse for us, b/c it means that while we might be getting an accurate count of free memory, we're actually losing heap space that we can never reclaim ourselves. Any thoughts?
|
|
Deanna Trollop
BZ Enterprises
Join date: 30 Jan 2006
Posts: 671
|
03-20-2007 14:17
From: Deanfred Brandeis This leads me to believe that garbage collection might not be happening properly when using some of the by-value list copy functions (llListReplaceList(), llListReplaceList(), llListDeleteSubList(), etc.) (I'll assume one of those llListReplaceList()s was supposed to be llListInsertList()  ) I've taken to using Strife's trick of prepending ( List = [] ) + to all list references which will alter the original, e.g. SomeList = llDeleteSubList( ( SomeList = [] ) + SomeList, 1, 1 );
(For that matter, I do the same for strings, since I've abandoned using lists all but entirely, in favor of strings containing fixed-length elements, as they don't waste nearly as much memory per-element as lists do... but I digress) Would this alter the results of your tests, Deanfred?
|