Jump to content

Failure in simplicity


steph Arnott
 Share

You are about to reply to a thread that has been inactive for 1042 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

56 minutes ago, Love Zhaoying said:

Biggest thing I learned recently is, use as few functions as possible to save memory.

While maybe generally true, even user-defined functions don't always take up more memory in Mono, only when "needed." I'm not entirely sure what the criteria is for when and how much memory is allocated, though. For example, all of this is in state_entry with no other states:

llOwnerSay((string)llGetUsedMemory()); // 3364 bytes
llOwnerSay((string)llGetUsedMemory()); // 3364
llOwnerSay((string)llGetUsedMemory()); // 3364
llOwnerSay((string)llGetUsedMemory()); // 3876
integer a = 1;
integer b = 2;
integer c = 3;
integer d = 4;
llOwnerSay((string)llGetUsedMemory()); // 3876

So.. memory usage went up by 512 bytes before and after. This might be explained by memory allocated for bytecode in chunks of 512. The same behavior is seen when moving the integers to a user-function and calling that function. (Even though it does nothing but declare local variables and not use them. Unused functions get optimized out and consume no memory.) But...

userfunc()
{
    llOwnerSay("hi");
}

default
{
    state_entry()
    {
        llOwnerSay((string)llGetUsedMemory()); // 3876 (7*512 + 292), same as with the integers earlier
        userfunc();
        llOwnerSay((string)llGetUsedMemory()); // 3920 (+44)
    }
}

Calling the user function only took up 44 bytes by the time the function had returned and memory was checked again. If the second llGetUsedMemory is put inside of userfunc, the memory use increases by an additional 4 bytes, still not quite 512.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

7 hours ago, Wulfie Reanimator said:

If the second llGetUsedMemory is put inside of userfunc, the memory use increases by an additional 4 bytes, still not quite 512.

Add a couple more user functions of any meaningful size, and you will see that on average, each 2 functions (?) adds 512..

Link to comment
Share on other sites

31 minutes ago, Love Zhaoying said:

Add a couple more user functions of any meaningful size, and you will see that on average, each 2 functions (?) adds 512..

The point I was making is that unlike what a lot of people think (that a function will take up 512 when used) isn't really true. Using multiple custom functions will inevitably cross the threshold for another 512 bytes, but so will a few regular variables, or a list. In general, especially if you're only using under or around 10KB of memory in total, optimizing memory use really shouldn't be your concern, it's called premature optimization. Everybody should read about it, it's kind of interesting.

  • Like 1
Link to comment
Share on other sites

4 minutes ago, Wulfie Reanimator said:

The point I was making is that unlike what a lot of people think (that a function will take up 512 when used) isn't really true. Using multiple custom functions will inevitably cross the threshold for another 512 bytes, but so will a few regular variables, or a list. In general, especially if you're only using under or around 10KB of memory in total, optimizing memory use really shouldn't be your concern, it's called premature optimization. Everybody should read about it, it's kind of interesting.

I don’t disagree. On the other hand, I’ve saved maybe 16k when I really, really needed it by using a minimal number of functions.

  • Like 1
Link to comment
Share on other sites

16 hours ago, steph Arnott said:

Okay, well basically it asks the server to allocate an up usage limit. That allows the server to use the rest for other code. On a script that does not vary its memory usage it is a waste of valuable available resources. Most code in SL never exceeds 10k. The above script is set to 7k, that is 57k that can be used elsewhere. Times that 57 by a hundred that is ni on 5.5MB of dead usage. The server at stress levels will start dropping scripts run time. Though someone far smarter on server memory allocation would give better informed answer. Simply fact is that a door script does not need 64k allocted to the script.

16 hours ago, Wandering Soulstar said:

Good to know and something I did not know .. Thanks @steph Arnott

You didn't know it because it's incorrect. Wolfie gently supplied the correct information, but it may help to point out what's actually wrong here. llSetMemoryLimit() does not free up memory for anything. In Mono memory is free until it's used, it is never "dead usage" nor "a waste of available resources", and scripts are not "allocated" 64KB -- they're allocated precisely as much memory as they're using (aside from what should be garbage-collected but isn't). Instead llSetMemoryLimit does exactly what it says on the tin: it establishes a limit on how much memory the script may end up allocating for its use, above which it will crash. The only other effect is that it exposes that limit to the sim and to other objects' scripts (via OBJECT_SCRIPT_MEMORY). As far as affecting actual sim performance, llSetMemoryLimit burns a few instructions when called, causes some scripts to crash, and that's it.

 

Link to comment
Share on other sites

9 minutes ago, Qie Niangao said:

As far as affecting actual sim performance, llSetMemoryLimit burns a few instructions when called, causes some scripts to crash, and that's it.

But to reiterate on what I said in my last paragraph of my correcting post, I believe using a memory limit decreases the time the sim spends calculating how much memory a Mono script is using while it's being prepared for transfer. (Sim crossing, rezzing, etc.) If you have no memory limit but have 90% free memory, the sim will theoretically waste 10x the time looking up where the allocated memory ends. A memory limit is a form of optimization and it should be used only when your script is past initial development and you know how much memory it realistically needs.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

I see some talking about memory limit and how the sim handles scripts and so on.

Fact is that none of you has even the slightest clue how this things are internally handled. So reading that made me laugh.

Until this things are officially documented by LL - I will NOT use llSetMemoryLimit because it has zero effect. Every talking about that is guessing and fairy tales and I don't believe in fairy tales - they only entertain me. :)

Link to comment
Share on other sites

29 minutes ago, Nova Convair said:

I see some talking about memory limit and how the sim handles scripts and so on.

Fact is that none of you has even the slightest clue how this things are internally handled. So reading that made me laugh.

Until this things are officially documented by LL - I will NOT use llSetMemoryLimit because it has zero effect. Every talking about that is guessing and fairy tales and I don't believe in fairy tales - they only entertain me. :)

How memory is handled internally is not a mystery, we've had Lindens talks about it (and Mono in general, specially in that one 1 hour(?) long panel) in great technical detail and more intricacies have been collectively documented on the official wiki. For what it's worth, I have experience with other programming languages as well so I have a more general understanding supporting my (admitted) speculation.

Edited by Wulfie Reanimator
  • Like 3
Link to comment
Share on other sites

5 minutes ago, Wulfie Reanimator said:

How memory is handled internally is not a mystery, we've had Lindens talks about it (and Mono in general, specially in that one 1 hour(?) long panel) in great technical detail and more intricacies have been collectively documented on the official wiki.

Just curious, have you seen or done tests that show a noticeable difference with scripts on sim crossings when memory limits are set?

Link to comment
Share on other sites

43 minutes ago, Nova Convair said:

I will NOT use llSetMemoryLimit because it has zero effect.

sometimes is best to script test before saying stuff like this

when we set memory limit to less than the static compiled size then llSetMemoryLimit has no effect. Which is expected behaviour as it makes no sense to do to this

when we set it to more than the static compiled size then the script will crash with a Stack-Heap Collision when the memory limit we have set is exhausted at runtime

example test which has a static compiled size of 4432 bytes

list stuff;

default
{
    state_entry()
    {
       llOwnerSay((string)llGetUsedMemory()); 
      
       llSetMemoryLimit(6000);
       llSetTimerEvent(1.0);
    }

    timer()
    {
        llOwnerSay((string)llGetUsedMemory());
        stuff += [
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF" +
           "0123456789ABCDEF"
        ];
    }
}

 

  • Like 2
Link to comment
Share on other sites

41 minutes ago, Wulfie Reanimator said:

... For what it's worth, I have experience with other programming languages as well so I have a more general understanding supporting my (admitted) speculation.

Yeah, I was gonna say, Mono is not an LSL-specific thing (although the LSL implementation might be special), so somebody with broader Mono experience -- that's definitely not me -- might have a pretty good idea what Babbage & team must have done back then.

(I also realize that my naive notion of what Mono does to transfer scripts from sim to sim was likely completely wrong, modeled on JSON serialization that really shouldn't be needed between identical environments.)

  • Like 1
Link to comment
Share on other sites

2 hours ago, Qie Niangao said:

You didn't know it because it's incorrect. Wolfie gently supplied the correct information, but it may help to point out what's actually wrong here. llSetMemoryLimit() does not free up memory for anything. In Mono memory is free until it's used, it is never "dead usage" nor "a waste of available resources", and scripts are not "allocated" 64KB -- they're allocated precisely as much memory as they're using (aside from what should be garbage-collected but isn't). Instead llSetMemoryLimit does exactly what it says on the tin: it establishes a limit on how much memory the script may end up allocating for its use, above which it will crash. The only other effect is that it exposes that limit to the sim and to other objects' scripts (via OBJECT_SCRIPT_MEMORY). As far as affecting actual sim performance, llSetMemoryLimit burns a few instructions when called, causes some scripts to crash, and that's it.

 

Suggest you check your facts. Start with the fact that threr are two momo versions in use.

Link to comment
Share on other sites

2 hours ago, Love Zhaoying said:

Just curious, have you seen or done tests that show a noticeable difference with scripts on sim crossings when memory limits are set?

Sadly no, but the change is noticeable between Mono and LSO, where LSO becomes responsive much faster, even in very stressed regions.

  • Thanks 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1042 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...