I have seen script that at the end of a scope also declare the local variables from the top of the scope to undefined. I know undefined variables get cleaned by the garbage collector, but is it necessary to also “undefine” variables from a local scope?
fn myScope =
(
local myVar = #()
-- dostuffhere
-- ...
myVar = undefined
)
What is good practice here, I’m building a tool that’s going to be used all over the place and I don’t want memory leaks. So is undefining good practice or not necessary when I local all my variables.
Thanks,
-Johan
the undefining of a local array doesn’t help you to free the memory. in theory free method has to do it but it doesn’t.
free <an_array>
so the only one way I know for sure that helps to keep memory from leaking is to call gc light:on after all extensive memory usages.
Hi Denis,
My special case for this question is loading temporary material libraries in a function in a scripted material. I have certain routines to load libraries on many or all scene materials, each special material calling it’s own library where it inherited materials from looking for an update. I’m worried about the loadTempMaterialLibrary variable not releasing the materials it loaded when it leaves the scope. How can I check it does, and it’s freeing the memory like it should.
Thanks,
-Johan
I’m absolutely sure that the system doesn’t release materials loaded with a temp library, and it doesn’t free memory. But I think it’s a different memory than used by scripts.
If you have MAX 2011+ you can check all material instances by getclassinstances with extra argument processAllAnimatables:on . The method has to show all loaded in local scope materials. But as I said the materials shouldn’t use free memory in the MAXScript heap. You can double check it by tracking heapfree before and after load (+ gc)
I thought a memory leak is when a value does not get picked up by the gc. How does calling gc light:on help free it?
why the ‘free’ method, should work? should we use it?
max only says about it in MeshProjIntersect / RayMeshGridIntersect…
I used var=undefined too, when testing memory leaks, but I didn’t notice a difference
I’ve seen max not releasing memory, not even with gc(), probably because max keeps some internal array until its replaced by max itself only.
it’s undocumented free method functionality:
free <array>
Frees the memory used by the array value without waiting for garbage collection.
Available in 3ds Max 9 and higher.
but as I said, it’s not working without GC. at least for me…
Would it help to move the tempMaterialLibrary functions out of the material and into some global utility library struct, I don’t want to destabilize a scene with possibly hundreds of materials all gathering more and more memory.
-Johan
i think it’s OK to have the tempMaterialLibrary functions as the scripted material’s static methods. But you have to care about not loading the same temp library with every material instance.
I don’t know a way to release created (loaded with library) materials. If so, load them at once, and reuse them later.
do you really see the leaking? how dramatic is it?
I have similar system for one of my scripted materials. It needs a set of special bitmaps. Only first loaded (or created) material generates this set, and all other instances of the material share it.
I’m running some more serious tests now and I see when calling my material function on each material memory goes through the roof, 250 times loading the loadTempMaterialLibrary. This memory is never released, not with reset, gc() or nothing, only max restart fixes this. HeapSize delta is also 0 before and after operation, so the tempLib doesn’t end up on the heap and doesn’t get gc’ed, so it’s probably not corrupting the scene, but is holding on to memory till max closes, right?
You suggestion is definitely the way to go and should be too hard to implement, I even figure it will run faster as well.
I’ll report back,
-Johan
i my case i cared more about scene loading time. but of course it saves the memory as well.
Running it with loading 1 library is definitely stopping the memory from increasing, and it also runs much faster then loading all the library’s on all materials.
So that’s good progress
-Johan