Please make a test for me

#1

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 timeChanged

after I get some numbers from my and your tests, I will share my thoughts

#2

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]
#3

– 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

#4

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 ?

#5

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

#6

Do you have any ideas about this lug? What can I guess, it’s something Nitrous…

#7

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

3dsmax.exe

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
изображение.png1250x280 59.7 KB

#8

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 :face_with_raised_eyebrow:

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

#9

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

#10

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.

#11

Maybe 3ds max “executs/runs” something each time when the time slider starts moving?