llGetFreeMemory and llGetSPMaxMemory do not work under Luau
planned
Frionil Fang
Not much more to it. llGetFreeMemory report 16000s bytes free at all times, llGetSPMaxMemory reports 16384 whether profiling is on or off. Same applies to pure Luau scripts, neither function returns meaningful values.
~~llGetUsedMemory and ll.GetUsedMemory appear to be ok.~~ <- Edit: redacted, they do not count memory used by tables or strings at all. A table with 10000 random numbers in it is reported as not using any memory, as well as a string with 256k(! that can't be right either) characters. Same applies to lists when compiled as LSL-Luau.
Log In
H
Harold Linden
planned
Signal Linden
tracked
This is intentional for now as we tune the garbage collector to actual workloads. We're still working out what allocations scripters should count against the memory limit and which should not, and didn't want to give people the wrong impression of memory usage in the meantime.
For the record,
gc.gcinfo()
isn't going to be representative of what might be returned from ll.GetFreeMemory()
in production because it includes a lot of internal bookkeeping allocations that wouldn't count because they aren't the "fault" of the scripter. For example, we've modified the Luau VM to keep the same table iteration order across VM reloads, and allocations for that are likely included in gcinfo()
. Additionally, we have a bunch of debugging instrumentation included by default in the bytecode at the moment, and that won't be there by default in production.rhet0rica Resident
llGetMemoryLimit() is also useless: https://feedback.secondlife.com/luau-alpha/p/llgetfreememory-and-llgetmemorylimit-report-bogus-values-under-lsl-luau
Kristy Aurelia
Supposedly the
gcinfo()
native lua function gives you "the total heap size in kilobytes, which includes bytecode objects, global tables as well as the script-allocated objects.". But considering not all memory related functions are working, it might be hard to tell if the gcinfo()
is accurate either, and it seems to be returning value in bytes rather that kilobytes.