Little Experiment

So It was too hot to sleep, so I wrote this really little snippet to test something, and got a very strange result:

default
{
    state_entry()
    {
        llOwnerSay((string) llGetFreeMemory() + " memory used before function call");
        llMessageLinked(LINK_THIS, 100, "", "temp");
        llOwnerSay((string) llGetFreeMemory() + " memory used after function call");
        llMessageLinked(LINK_THIS, 100, "", "temp");
        llOwnerSay((string) llGetFreeMemory() + " memory used after 2nd function call");
    }

    touch_start(integer total_number)
    {
        llOwnerSay((string) llGetFreeMemory() + " memory used in touch before function");
        llMessageLinked(LINK_THIS, 100, "", "temp");
        llOwnerSay((string) llGetFreeMemory() + " memory used after first touch function call");
        llMessageLinked(LINK_THIS, 100, "", "temp");
        llOwnerSay((string) llGetFreeMemory() + " memory used after 2nd touch function call");
    }
}

Output: (LSO compilation)
Output: 15503 memory used before function call
Output: 15490 memory used after function call
Output: 15490 memory used after 2nd function call

First Touch:
Output: 15473 memory used in touch before function
Output: 15473 memory used after first touch function call
Output: 15473 memory used after 2nd touch function call

Second Touch:
Output: 15473 memory used in touch before function
Output: 15472 memory used after first touch function call
Output: 15472 memory used after 2nd touch function call

Third touch:
Output: 15470 memory used in touch before function
Output: 15470 memory used after first touch function call
Output: 15469 memory used after 2nd touch function call

Fourth+ touch:
Output: 15469 memory used in touch before function
Output: 15469 memory used after first touch function call
Output: 15469 memory used after 2nd touch function call

Is this strange behavior that the script keeps eating some memory until the fourth touch, or is this expected behavior? The Mono results are erratic, why I didn't post them.

interestingly enough I get the EXACT same sequence of values. so I tweaked a few things.... it's in the string handling. your strings are pushings the stack size, and after the first call there is a link message waiting to be handled (13bytes by the look of it... plus that extra 4 to push the watermark when entering the touch event (probably the touch count, or a reference to it)

try it with the owner say lines all the same, it'll be Mark, drop13, duplicate, then touch yields drop4, duplicate, duplicate

ETA check that, it's purely in stack call that adds the strings together and converts the results... 6 ownersay/GetFreeMemory cals with the same layout, runing the call push the stack watermark up AFTER the call is made by 13 bytes, and then the addition of the variable in the event code (or perhaps just a pointer to the current event) push it anothe 4 on top of that.

and my afternoons waste of time.... a listing of the LSO byte sizes for basic declared variables in various places in a script....

if you don't have the fun stuff to see proper formatting on the forum hit quote copy all, paste in notepad to see it correctly, or see my sig for a link to get the fun stuff

Base Byte Cost by Variable Type and Explanation of Costs
rotation  21  =  2(type_value) + 4(32bit_float_storage)*4 + 3[Unknown]
vector    16  =  2(type_value) + 4(32bit_float_storage)*3
float      6  =  2(type_value) + 4(32bit_float_storage)
integer    6  =  2(type_value) + 4(32bit_signed_integer)
string     3+ =  2(type_value) + [1/character] + 1(termination_character)
key        3+ =  2(type_value) + [1/character] + 1(termination_character) {standard key is 39}
list       6+ =  2(type_value) + [1(termination_character?)/element + element_Base_Cost] + 4[Unknown]

Additional Declaration Costs by Location and type
         + - - - - - - - - - - - - - - - - - -| Globals | Events | Function Interior |
         | Declaration Type                   |  Cost @ |  Cost  |  Cost             |
=========+=================================== +=========+========+===================+
         | <1.0, 1.0, 1.0, 1.0>;              |    -    |   +0*  |   +0*             |
rotation | rotation x;                        |   +1    |  +18   |   +2              |
         | rotation x = <1.0, 1.0, 1.0, 1.0>; |   +1    |  +21*  |   +5*             |
=========+=================================== +=========+========+===================+
         | <1.0, 1.0, 1.0>;                   |    -    |   +0*  |   +0*             |
  vector | vector x;                          |   +2    |  +15   |   +3              |
         |  vector x = <1.0, 1.0, 1.0>;       |   +2    |  +17*  |   +5*             |
=========+=================================== +=========+========+===================+
         | 1.0;                               |    -    |   +0*  |   +0*             |
   float | float x;                           |   +4    |   +9   |   +5              |
         | float x = 1.0;                     |   +4    |   +9*  |   +5*             |
=========+=================================== +=========+========+===================+
         | 1;                                 |    -    |   +0   |   +0              |
 integer | integer x;                         |   +4    |   +9   |   +5              |
         | integer x = ;                      |   +4    |   +9   |   +5              |
=========+=================================== +=========+========+===================+
         | "";                                |    -    |   +0   |   +0              |
 string  | string x;                          |  +15    |   +9   |   +5              |
         | string x = "";                     |  +15    |   +9   |   +5              |
=========+=================================== +=========+========+===================+
         | [not applicable]                   |    -    |    -   |    -              |
     key | key x;                             |  +15    |   +9   |   +5              |
         | key x = "";                        |  +15    |  +11** |   +7**            |
=========+=================================== +=========+========+===================+
         | [];                                |    -    |   +0   |   +0              |
    list | list x;                            |  +15    |   +9   |   +5              |
         | list x = [];                       |  +15    |   +9   |   +5              |
=========+=================================== +=========+========+===================+
* = each implied typecast to float adds 2 bytes to the declaration. that's up to +8
    bytes for a rotation declared using all integers such as <1, 1, 1, 1>

**= there is no way to implicitly declare a key and assignment using quotation marks
    is considered a string which requires a typecast, hence the 2 byte difference from
    strings when assigning a value at declaration.

@ = it is impossible to implicitly declare variables in globals section of a script.
    Further, any implied typecasts (integers where floats are expected or strings
    where keys are expected) are handled by the compiler and do not add to code size.

I haven't done variables by reference, or in function calls, nor in function declarations or return code lengths yet, but it's a good start

PS notice the weird extra 3 bytes in rotations? or the extra 4 in lists(element count perhaps)? anyone know what those do?

Only thing I could think of is perhaps it's a private variable of some type in those objects? But think that would be too simple an answer

I posted a thread looking for someone to handle a project for me asap. It seems like it wouldn't be hard but I am not a scripter.

See Scripter desperately needed!

Thanks!

Try the Services forum. This is the place to come if you want to learn how to write scripts yourself.

Ok. Since everyone keeps telling me to move to different forums...




Then how do delete my posts?

Sorry for the run around, it is just because people with different skills pay attention to a different set of forums. You have a much better chance of getting a correct answer when it is in the right place. But several different skills watch Products Wanted, Services & Employment Ops which are for hire forums.

You do not need to worry about deleting the threads, they will be back a couple of pages in a day or so.

Hope this helps.

Thank you!

Originally this started as an experiment to see if declaring variables in a function call was cheaper then declaring a global, like in the link message for the key where I put temp. If it would be cheaper to just hard code it, or to have a global. I notice at first it's cheaper, and that in an event, it seems to save that variable for further use if used again. So I wanted to see if it saved it cross events. Needless to say I got side tracked with the results, so going to try again, but maybe someone out there has the answer.

example:

llMessageLinked(LINK_THIS, 100, "", "temp";

vs.

key TEMP = "temp";

llMessageLinked(LINK_THIS, 100, "", TEMP);

I would think that if you use TEMP multiple times it would be a memory savor, but so far, via my little experiment, it doesn't look that way. But I'll test more.

well, lets refer to the chart I posted....

declare key temp = "temp"; in the global section
3 bytes+ 4characters + 15 for the global overhead (sick no?) = 22bytes just to declare if declared inside a function 14, and in an event, 18.... but we need the globals, so 22 it is

each reference to a variable costs 6 bytes (IIRC) so every time you need to use temp, that's 6 bytes, but in the context of a function that takes key, undeclared string will be automatically typecast to string (can't remember if there's a byte cost, but there is absolutely a speed cost.) assumming the typecast is free, a 4 character string that isn't being declared is 7bytes of code. where as the reference to the global is only 6... so with a little basic math, you breakeven point is 22 references to the global versus 22 instances of just typing "temp" where key casting happens automattically. if it isn't cast automatically, then add 2 bytes per "temp" and your break even point is 7 iterations.

(yeah I know that type cast cost are not included above (although you can guess key cast cost from it), nor are reference variables(6 IIRC)... haven't got there yet... and truth be told the above chart actually counts 3 different things in two different places... creation, assigment, and value.. but I wanted to make it more readable for people.)

PS based on the above chart, declaring keys string and lists is most expensive in the globals, least in events, and least of all for literals anywhere. all the declared math variables are cheapest as globals, and most expensive in events, with literals again being the cheapest.

fun fact (integer)"1" is cheaper than 1 (and possibly cheaper than TRUE, gotta check) but is slower and will bump up the runtime watermark to be the same