Talk:LSL Script Memory
Has anyone tested the new MONO environment for memory usage? It seems its very different from the previous LSO numbers... I think a new section for MONO is needed.--Darwin Recreant 21:21, 4 December 2008 (UTC)
Size of Strings under Question
Unsure of code used by others to determine the size of a local string under Mono but my testing seems to show that a string is approximately 24 bytes + 1 per char. This is the code I'm using with the length of variable "i" such that the addition of one more character causes another page being allocated for memory used. Uncommenting each Test in turn and rerunning it with one additional character in any of the string variables (to show that you are actually at the edge of a page) should show you what I'm finding. Perhaps I'm misinterpreting the results??? <LSL>default {
state_entry()
{
// Test 1, add one char to string for memory jump of a page
string i = "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmn";
// Test 2 - difference of 32 bytes in variable "i"
// string i = "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghi";
// string j = "a";
// Test 3 - difference of 27 bytes in variable "i"
// string i = "abcdefghijklmnopqrstuvwxyzabcdefgh";
// string j = "a";
// string k = "b";
// Test 4 - difference of 26 bytes in variable "i"
// string i = "abcdefgh";
// string j = "a";
// string k = "b";
// string l = "c";
llOwnerSay((string)llGetFreeMemory()); }
}</LSL> LepreKhaun Resident 13:06, 19 December 2013 (PST)
- Hello LepreKhaun. This page [[1]] states that strings in Mono are encoded in UTF-16 and require 2 bytes per character. Omei Qunhua 14:55, 19 December 2013 (PST)
- Yes, you're right, though the page fronting this states (within a local scope) it is only 1 byte per char. But then that makes my observation even more so- apparently the base cost of each string is twice what I was looking at, app 48 bytes (which is 4 times that of what is shown on the page fronting this). Yes?
- Hello LepreKhaun. This page [[1]] states that strings in Mono are encoded in UTF-16 and require 2 bytes per character. Omei Qunhua 14:55, 19 December 2013 (PST)
- Um ... I think the attached page needs some serious editing as a lot of those figures relate to "Pre Mono" or LSO. Strife suggested a rewrite in December 2012. No one has done it yet. :( Omei Qunhua 16:27, 19 December 2013 (PST)
- I am in so much agreement, what with other discrepancies being found by my testing methods (which may or may not be correct, the algorithms are still being refined).
The problem (as I see it) is that anyone can post a table of figures- a string/float/vector/operator is "that many bytes" of your program. But no one is showing the underlying algorithm (verification coding in LSL) they use to obtain those "facts". Lacking peer review of derivative algorithms, it really is impossible to determine how the SL implementation of Mono is deriving our program size at any given point.
[ETA This may really require a disambiguation page, LSO and SL's implementation of Mono are wickedly different. I'd suggest rolling back this to strictly LSO (which, in my limited experimentation, holds still) and having a link to the SL Mono implementation memory allocation. This would end the ambiguity of what applies when as well as separating what is known fact (LSO) from what might be supposed from working with the black box that is the SL Mono implementation (which does NOT conform with strict Mono btw).] LepreKhaun Resident 18:17, 19 December 2013 (PST)
- I am in so much agreement, what with other discrepancies being found by my testing methods (which may or may not be correct, the algorithms are still being refined).
- Um ... I think the attached page needs some serious editing as a lot of those figures relate to "Pre Mono" or LSO. Strife suggested a rewrite in December 2012. No one has done it yet. :( Omei Qunhua 16:27, 19 December 2013 (PST)
- If you look at my own page, [[2]], and one by Pedro Oval, [[3]] , you will see our findings for Mono usage for a large number of code snippets. These were obtained generally by replicating the snippet 512 times, which obviates the effect of Mono's 512-byte memory grabbing forays. I balked at trying to do the same for strings, as I have a feeling the strings would need to have different contents each time. But another technique I have used, is to add a series of minimum-space padding code snippets, until I observe the memory usage jumping to the next 512 multiple, doing this both with and without my target bit of code to be measured, and hence one can compute the space used by the target code. These padding code fragments were first measured via the 512-times approach. e.g. You could use a series of x; (at 2 bytes each) or x++; (at 8 bytes each) etc. But the occasional interference by garbage collection at run time, still makes the exercise a bit fraught at times. Hope this helps Omei Qunhua 19:04, 19 December 2013 (PST)
- Thank you, I've read those pages. Back to my original question, am I looking at a 48 byte base for local strings or not? And if not, where is the error in my approach?LepreKhaun Resident 21:43, 19 December 2013 (PST)
- If you look at my own page, [[2]], and one by Pedro Oval, [[3]] , you will see our findings for Mono usage for a large number of code snippets. These were obtained generally by replicating the snippet 512 times, which obviates the effect of Mono's 512-byte memory grabbing forays. I balked at trying to do the same for strings, as I have a feeling the strings would need to have different contents each time. But another technique I have used, is to add a series of minimum-space padding code snippets, until I observe the memory usage jumping to the next 512 multiple, doing this both with and without my target bit of code to be measured, and hence one can compute the space used by the target code. These padding code fragments were first measured via the 512-times approach. e.g. You could use a series of x; (at 2 bytes each) or x++; (at 8 bytes each) etc. But the occasional interference by garbage collection at run time, still makes the exercise a bit fraught at times. Hope this helps Omei Qunhua 19:04, 19 December 2013 (PST)
- I did some tests today based on your code, but using llGetUsedMemory(). Results were not consistent. Strings assigned to named variables within an event gave an overhead of from 40 to 50 bytes per string (plus the 2 bytes per character). Defining global strings suggested a larger overhead around 60 bytes per string. Strings coded within an event but not assigned to named variables, gave 12 bytes overhead per string. Rather depressing reading :) Omei Qunhua 08:49, 20 December 2013 (PST)
- Pedro Oval also saw non-consistent results from strings etc. [[4]] Omei Qunhua 15:57, 20 December 2013 (PST)
- Well strings are always funny critters and SLMono is provably non-deterministic at times. One thing I see lacking on the fronting page is the fact that the SLMono implementation has a base cost of 3364 bytes per program. That is to say, the minimal default state with one event is taking that amount off the top from the gitgo. I believe under LS0 it was 220-230 bytes???LepreKhaun Resident 08:39, 21 December 2013 (PST)
- And, of course, when one reads this: http://marc.info/?l=mono-devel-list&m=113761555126537&w=2 you have to wonder how accurate any measurement could ever be with the tools we have within LSL.LepreKhaun Resident 02:26, 28 December 2013 (PST)
Needed Updates
Using the script below I found a few unusual things happening. One of them seems to be a change in free script memory at the time of compilation. This script provided the data listed below it.<lsl>integer count;
default {
state_entry()
{
llSetTimerEvent(1.0);
}
timer()
{
llOwnerSay((string)llGetFreeMemory() + " , " + (string)(++count));
list l = ["", "", "", ""];
llOwnerSay((string)llGetFreeMemory());
}
touch_start(integer detected)
{
llResetScript();
}
}</lsl><lsl>[22:44] EddyFragment Robonaught: Test Begins [22:44] Object: 60664 , 1//Only just recompiled for touch reset. [22:44] Object: 60664 [22:44] Object: 60664 , 2 [22:44] Object: 60628 //Then evens out [22:44] Object: 60628 , 3 [22:44] Object: 60628 [22:44] Object: 60628 , 4 [22:44] Object: 60628 [22:44] Object: 60628 , 5 [22:44] Object: 60628 [22:44] Object: 60628 , 6 [22:44] Object: 60628 [22:44] Object: 60628 , 7 [22:44] Object: 60628 [22:44] Object: 60628 , 8 [22:44] Object: 60628 [22:44] Object: 60628 , 9 [22:44] Object: 60628 [22:44] Object: 60628 , 10 [22:44] Object: 60628 [22:44] Object: 60664 , 1//After a touch reset [22:44] Object: 60628 [22:44] Object: 60628 , 2 [22:44] Object: 60628 [22:44] Object: 60628 , 3 [22:44] Object: 60628 [22:44] Object: 60664 , 1 [22:44] Object: 60628 [22:44] Object: 60628 , 2 [22:44] Object: 60628 [22:44] Object: 60628 , 3 [22:44] Object: 60628 [22:44] Object: 60628 , 4 [22:44] Object: 60628 [22:44] Object: 60664 , 1 [22:44] Object: 60628 [22:44] Object: 60628 , 2 [22:44] Object: 60628 [22:44] Object: 60628 , 3 [22:44] Object: 60628 [22:44] Object: 60664 , 1 [22:44] Object: 60628 [22:44] Object: 60628 , 2 [22:44] Object: 60628 [22:44] Object: 60628 , 3 [22:44] Object: 60628 [22:44] Object: 60628 , 4 [22:44] Object: 60628 [22:44] Object: 60664 , 1 [22:44] Object: 60628 [22:44] Object: 60628 , 2 [22:44] Object: 60628 [22:44] Object: 60664 , 1 [22:44] Object: 60628 [22:45] Object: 60628 , 2 [22:45] Object: 60628 [22:45] Object: 60628 , 3 [22:45] Object: 60628 [22:45] Object: 60628 , 4 [22:45] Object: 60628 [22:45] Object: 60628 , 5 [22:45] Object: 60628 [22:45] Object: 60628 , 6 [22:45] Object: 60628 [22:45] Object: 60628 , 7 [22:45] Object: 60628 [22:45] Object: 60628 , 8 [22:45] Object: 60628 [22:45] Object: 60628 , 9 [22:45] Object: 60628 [22:45] Object: 60628 , 10 [22:45] Object: 60628 [22:45] Object: 60628 , 11 [22:45] Object: 60628 [22:45] Object: 60664 , 1 [22:45] Object: 60628 [22:45] Object: 60628 , 2 [22:45] Object: 60628 [22:45] Object: 60628 , 3 [22:45] Object: 60628 [22:45] Object: 60664 , 1//But this would happen (it seemed to me) after letting the script run a little more before the reset [22:45] Object: 60664 [22:45] Object: 60664 , 2 [22:45] Object: 60664 [22:45] Object: 60664 , 3 [22:45] Object: 60664 [22:45] Object: 60664 , 4 [22:45] Object: 60664 [22:45] Object: 60664 , 5 [22:45] Object: 60628 [22:45] Object: 60628 , 6 [22:45] Object: 60628 [22:45] Object: 60628 , 7 [22:45] Object: 60628 [22:45] Object: 60628 , 8 [22:45] Object: 60628 [22:45] Object: 60664 , 1 [22:45] Object: 60628 [22:45] Object: 60628 , 2 [22:45] Object: 60628 [22:45] Object: 60664 , 1 [22:45] Object: 60628 [22:45] Object: 60628 , 2 [22:45] Object: 60628 [22:45] Object: 60628 , 3 [22:45] Object: 60628 [22:45] Object: 60628 , 4 [22:45] Object: 60628 [22:45] Object: 60628 , 5 [22:45] Object: 60628 [22:45] Object: 60628 , 6 [22:45] Object: 60628 [22:45] Object: 60628 , 7 [22:45] Object: 60628 [22:45] Object: 60628 , 8 [22:45] Object: 60628 [22:45] Object: 60628 , 9 [22:45] Object: 60628 [22:45] Object: 60628 , 10 [22:45] Object: 60628 [22:45] Object: 60628 , 11 [22:45] Object: 60628 [22:45] Object: 60628 , 12 [22:45] Object: 60628 [22:45] Object: 60664 , 1 [22:45] Object: 60628 [22:45] Object: 60628 , 2 [22:45] Object: 60628 [22:45] Object: 60664 , 1//And here again [22:45] Object: 60664 [22:45] Object: 60664 , 2 [22:45] Object: 60664 [22:45] Object: 60664 , 3 [22:45] Object: 60664 [22:45] Object: 60664 , 4 [22:45] Object: 60664 [22:45] Object: 60664 , 5 [22:45] Object: 60628 [22:45] Object: 60628 , 6 [22:45] Object: 60628</lsl> -- Eddy (talk|contribs) 06:01, 2 July 2009 (UTC)
Thanks for the confidence boost and I thought so too. If getting inworld is still a problem for you tell me what to run and I'll happily do it for you. Otherwise my tests might be a bit less than useful. Those repeated 60664's are weird though. -- Eddy (talk|contribs) 23:53, 2 July 2009 (UTC)
It seems llGetFreeMemory() does not show true value and is dependent on sim performance (random like) on getting updated. I guess the only way to know true impact of operations and variables can only be tested after many subsequent tries similar to Eddy's method. --Darwin Recreant 08:51, 10 December 2009 (UTC)
I'd say the above observations were due the the random involvement of garbage collection. If you do an llSleep(2.0) or so before accessing llGetFreeMemory() you'll give garbage collection a good chance to get in, and results will be more consistent. But running this code in December 2012 did not show variation for me. So I'd guess this is an obsolete observation and this page can be revised down in size? Omei Qunhua 17:27, 28 December 2012 (PST)
List Storage Requirements (Mono) need updating
It appears that the storage requirements for lists in Mono have changed since this page was written. I plan to change the figures to those experienced in December 2012 as shown on my user page, unless anyone disagrees. Omei Qunhua 17:27, 28 December 2012 (PST)
- I would almost be inclined to suggest rewriting the article from scratch. It's an old article which had Mono info bolted one after the fact. -- Strife (talk|contribs) 21:13, 28 December 2012 (PST)
The article talks about datas collected by llGetFreemomry and not llGetUsedMemory . Are the samples collected recently using always this old function ?
Shouldn t have we some datas collected by llGetUsedMemory ? -- Miranda Umino 14:21, 16 February 2013 (PST)
Update pending
<lsl> //////////////////////////////////////////////////////////////////////////////// // // Script memory - work in progress // // (c) 1012 // llDeleteSubString( "yepey Resident", llSubstringIndex( "yepey Resident", " " ), -1 ); // // The script won't compile due to previously decalerd variables. // This script will, when finished, replace all of the above. // // Regards, // yepey // // // GLOBAL VARIABLES // -------------------------------------------------------------------- integer int = 0; // 8 float fl = 0.0; // 8 string str = ""; // 22 string str = "a"; // 22 + 2 string str = "\n"; // 22 + 2 key id = ""; // 8 key id = NULL_KEY; // 8 key id = "a822ff2b-ff02-461d-b45d-dcd10a2de0c2"; // 8 vector v = ZERO_VECTOR; // 16 vector v = < 0, 0, 0 >; // 16 rotation r = ZERO_ROTATION; // 16 rotation r = < 0, 0, 0, 1 >; // 16 list l = []; // 44 list l = [ // 44 + o.O
0, // 28
1.0, // 28
"", // 30
"a", // 32
"\n", // 32
NULL_KEY, // 102
ZERO_VECTOR, // 36
ZERO_ROTATION // 40
];
default {
state_entry()
{
// LOCAL VARIABLES // ------------------------------------------------------------------------
integer int = 0; // 4
float fl = 0.0; // 4
string str = ""; // 18 +
string str = "a"; // 2
string str = "\n"; // 2
key id = ""; // 4
key id = NULL_KEY; // 4
key id = "a822ff2b-ff02-461d-b45d-dcd10a2de0c2"; // 4
vector v = ZERO_VECTOR; // 12
vector v = < 0, 0, 0 >; // 12
rotation r = ZERO_ROTATION; // 16
rotation r = < 0, 0, 0, 1 >; // 16
list l = []; // 40
list l = [ // 40 + o.O
0, // 16
1.0, // 16
"", // 18 +
"a", // 2
"\n", // 2
NULL_KEY, // 90
ZERO_VECTOR, // 24
ZERO_ROTATION // 28
];
}
}
state examples {
state_entry()
{
/* IMPLEMENTATION NEEDED */
}
} </lsl> Joanne Furlough 20:07, 5 May 2013 (PDT)