Could you run this snippet and tell me the output in the listener when you change the time with the time slider…
please try it in empty scene… and please tell me your MAX version. If you can do the test in different version please do it. Thanks!
global LAST_HEAP = 0
unregisterTimeCallback timeChanged
fn timeChanged =
(
heap = heapfree
print [currenttime, ::LAST_HEAP - heap]
::LAST_HEAP = heap
)
registerTimeCallback timeChangedafter I get some numbers from my and your tests, I will share my thoughts
For frames 1 to 6 I move the Time slider using its right arrow. From 7-9 I drag the time slider.
-- max 2016
[1,-4.82638e+008]
[2,56]
[3,56]
[4,56]
[5,56]
[6,56]
[7,312]
[8,56]
[9,64]
[9,64]
-- max 2020
[1,-5.08008e+08]
[2,332]
[3,332]
[4,332]
[5,332]
[6,332]
[7,254572]
[8,64]
[9,64]
[9,68]
-- max 2022
[1,-4.7807e+08]
[2,332]
[3,60]
[4,332]
[5,332]
[6,332]
[7,112248]
[8,60]
[9,60]
[9,60]This is from max2020. Dragging the time slider. Big numbers occurs only when I start new drag – on frames 2, 8, 14, 20.
[2,515680]
[3,60]
[4,64]
[5,68]
[6,68]
[7,68]
[7,68]
[8,511752]
[9,60]
[10,60]
[11,60]
[12,60]
[13,60]
[13,60]
[14,512644]
[15,60]
[16,60]
[17,60]
[18,60]
[19,60]
[20,60]
[21,60]
[21,60]
[20,510412]
[21,60]
[22,60]
[23,60]
[24,60]
[25,60]
[26,60]
[27,60]
[27,60]
– 2014
::LAST_HEAP - heap is 64 for any frame
– 2020
::LAST_HEAP - heap is 60 most of the time. But each time I grab and start moving the slider it is smth like this [152,496460] no matter which frame it is. No such behavior in 2014
All tests done with empty scenes, fresh start.
Most stable versions seems to be 2016, 2022, 2023.
Doing another action (opening a menu, creating an object, etc) and then moving the slider leads to higher values, except in Max 2022 and 2023 which are more similar.
Clicking on timebar or slider in Max 2018, 2020 seems to consume around 250Kb of Heap per click, around 500Kb mousedown+mouseup. Not the same behavior using the arrows or playback controls.
Half the Heap in Max 2022 and 2023 and almost nothing in Max 2016.
MAX 2016
Click on timebar or slider
1088
Continues drag slider or click on slider arrows
64
Switching between actions, drag, click on arrows or timebar
576 / 1088
MAX 2018
Click on timebar or slider
486540 ?
Continues drag slider or click on slider arrows
60
Switching between actions, drag, click on arrows or timebar
240176 / 480276 ?
MAX 2020
Click on timebar or slider
-191852 / 65624
Continues drag slider or click on slider arrows
68
Switching between actions, drag, click on arrows or timebar
240176 / 480276 ?
MAX 2022 – 2023
Click on timebar or slider
222028 ?
Continues drag slider or click on slider arrows
64
Switching between actions, drag, click on arrows or timebar
111020 / 222004 ?
Thank you, guys! I have enough material to think…
I see the same problem that I have:
[2,332]
[3,332]
[4,332]
[5,332]
[6,332]
[7,254572]
[8,64]
[9,64]
[9,68]this behavior puzzles me
Do you have any ideas about this lug? What can I guess, it’s something Nitrous…
It doesn’t look like there’s a lot to be done on mouse click at least in 2014 version.
I don’t have .pdb files for other versions so can’t really check if there’re any differences
without knowing how heapfree is calculated it’s just pissing in the wind could be a glitch or not from anywhere, looking a maxheapdirect.h in the SDK there’s no getmaxheapsize function as such… without the source who knows how it’s calculated. I’d guess they walk the heap and sum whats available… some flag gets flipped and spurious results result.
blimey they are usingarcane win32
even more arcane not windows per se perhap ms malloc implementation ??seems it’s not a C/C++ thing
though
def_visible_primitive(get_max_heap_free_size, "get_max_heap_free_size");
Value* get_max_heap_free_size_cf(Value** arg_list, int count)
{
enum args { knum_args };
check_arg_count(get_max_heap_free_size, knum_args, count);
_HEAPINFO hinfo;
unsigned int size = 0;
int heapstatus;
hinfo._pentry = NULL;
while ((heapstatus = MAX_heapwalk(&hinfo)) == _HEAPOK)
{
if (hinfo._useflag == _FREEENTRY)
size += hinfo._size;
}
return Integer::intern(size);
}
def_visible_primitive(get_max_heap_size, "get_max_heap_size");
Value* get_max_heap_size_cf(Value** arg_list, int count)
{
enum args { knum_args };
check_arg_count(get_max_heap_size, knum_args, count);
_HEAPINFO hinfo;
unsigned int size = 0;
int heapstatus;
hinfo._pentry = NULL;
while ((heapstatus = MAX_heapwalk(&hinfo)) == _HEAPOK)
size += hinfo._size;
return Integer::intern(size);
}
neither of these functions tally with mxs
heapsize
running the original script in 2010 produces a constant value e,g
[37,72]
[38,72]
[39,72]
[40,72]
[41,72]
[42,72]
[43,72]
[44,72]
[44,72]
though running the free function above
get all sorts 0, positives and minus
yes, it puzzles me, as I said. I can understand the negative memory lug (which means garbage collection), but I can’t explain this constant lug in an empty scene. The same behavior it seems like take place in scripted controllers.
Maybe 3ds max “executs/runs” something each time when the time slider starts moving?