llGetUsedMemory - Returning the same value

[Senelya Bloodrose]

I'm hoping someone can may be explain if I'm not understanding some thing correctly. I've been trying to optimize memory for a script but the it's really confusing using llGetUsedMemory.

I tried to do a quick, simple test where I had a global list variable and every time I touched the scripted object, it would add a randomized string to it and then print out the memory usage. What I found is that llGetUsedMemory just keeps returning the same value after adding several new list items.

What am I missing? Are scripts auto allocating a big chunk of memory for my list and I'm not adding enough elements in my test to increase/reallocate/resize for more memory for the list variable?

[Marvin Benelli]

According to SL Wiki a fixed value is returned for scripts using the old LSO model. Did you maybe forget to tick the Mono checkmark in your script?

[Mollymews]

conversation about LSL Mono memory fragmentation garbage collection is here

 

[Senelya Bloodrose]

4 hours ago, Marvin Benelli said:

According to SL Wiki a fixed value is returned for scripts using the old LSO model. Did you maybe forget to tick the Mono checkmark in your script?

Wow... when I disabled Running to test some stuff I guess it also unchecked Mono as well. I checked it back on and looks like the memory value is updating properly. Such a simple mistake, thanks for pointing it out! Saved me a lot of time debugging!

[Quistess Alpha]

55 minutes ago, Senelya Bloodrose said:

Wow... when I disabled Running to test some stuff I guess it also unchecked Mono as well.

IIRC scripts created in inventory can also default to mono being off. always a good idea to keep the mono and running check-boxes as one of the obvious things to check in your mental "why is this not working?" checklist.

[Coffee Pancake]

10 hours ago, Senelya Bloodrose said:

What am I missing? Are scripts auto allocating a big chunk of memory for my list and I'm not adding enough elements in my test to increase/reallocate/resize for more memory for the list variable?

Memory is allocated in 512byte chunks - This is the minimum allocation for new functions, event handlers and global variables.

So, say you create a few globals, that costs you 512bytes .. add some data to them later, if you don't go over that 512 byte allocation, you you're not using more memory.

This is why you should be careful applying modern best practices to LSL scripts.

 

Edit - to add Global variables don't get 512bytes each, the first costs you 512bytes the rest fill up that allocation, till you go over then another 512bytes chunk is allocated.

Edited May 13, 2022 by Coffee Pancake

[Senelya Bloodrose]

9 hours ago, Quistess Alpha said:

IIRC scripts created in inventory can also default to mono being off. always a good idea to keep the mono and running check-boxes as one of the obvious things to check in your mental "why is this not working?" checklist.

Yup, I just started trying to fine tune and optimize so will add that to my new mental check list.

 

5 hours ago, Coffee Pancake said:

Memory is allocated in 512byte chunks - This is the minimum allocation for new functions, event handlers and global variables.

So, say you create a few globals, that costs you 512bytes .. add some data to them later, if you don't go over that 512 byte allocation, you you're not using more memory.

This is why you should be careful applying modern best practices to LSL scripts.

 

Edit - to add Global variables don't get 512bytes each, the first costs you 512bytes the rest fill up that allocation, till you go over then another 512bytes chunk is allocated.

Hm that's really interesting. Though I'm not sure I fully grasp the concept. Does that mean all memory are allocated in 512 byte allocation blocks? If so, I would expect that the get used memory function would always be a multiple of 64KB (or 512b?). But I just tested and I get a non-multiple. I have seen that making modifications sometimes reduces memory, but other times it doesn't so I guess this could explain some of it. However, I think I'd need more explanation of what gets in 512b blocks and what doesn't.

[Quistess Alpha]

1 minute ago, Senelya Bloodrose said:

However, I think I'd need more explanation of what gets in 512b blocks and what doesn't.

That's part of LL's secret sauce. I think the only way to know for sure is to create some tests and run them.

[Senelya Bloodrose]

40 minutes ago, Quistess Alpha said:

That's part of LL's secret sauce. I think the only way to know for sure is to create some tests and run them.

Yea, I've tried some tests but they seem so inconsistent which is in line with the lsl wiki on memory on how the numbers are necessarily conclusive given the LL secret sauce. Thought maybe some might know but the info wasn't posted. Wishful thinking.

[Coffee Pancake]

the best advice I can give it to get your script working 100% with readable clean code and then worry about optimization *IF* you need more working memory space (eg for data storage or to save needing a second script). I would avoid the fs preprocessor and highly recommend an external editor like vscode - keep your readable code as a comment, future you will thank you !!

inlining / merging small / medium functions and variable reuse are good places to start - you know, all the stuff modern programming practices say you shouldn't do

the lsl memory profiling tools will slow your script down, but will save your bacon

key compression can be useful if you need to get the keys back later, if you just need to know you have seen a key before use a hash instead

If you have lots of text strings, move them to a notecard and use a dataserver event to read specific lines in as and when you need them .. its a pain in the butt, but can mean the difference between something fitting in one script or three. It also makes localization a lot simpler.

If you end up messing about with extravagant tree like menu structures .. consider a HUD instead

[Frionil Fang]

I'll also add that you may want to sleep a single frame (i.e. llSleep(0.01) to ensure the current server frame ends before the next line executes) before checking for free memory. Had a super constrained script that kept crashing despite seemingly having a couple kB left, but the "free memory" number appears to be updated only at the start of a frame, so it may not be in sync with your operations that are actually consuming the memory.

[SalvadorNL]

also if your script is around 60k you might want to use llGetSPMaxMemory to make sure it doesn't crash when pushed to the max