MXS 2017 'For Loop' performance

#1

Do you guys get the same ‘for loop’ performance in MXS 2017 and previous versions?

(
st = timestamp()
for j = 1 to 1000000 do ()
format "time:%
" (timestamp()-st)
)
MXS unexplained problem... memory leaking
#2 
Max 2016: time:311
Max 2017: time:581
#3 
Max 2016: time:344
Max 2017: time:667
#4 
 Max2016: time:177
 Max2017: time:353

curious about your machine specs, mine is a i7-4930K @ 4.3GHz

#5

max version:19000 time:398 (max 2017)

max version:16000 time:227 (max 2014)

I hope max team fix this and many problem on maxscript editor on next update.

#6

Thank you so much guys. That’s explains why everything is sooo slow in 2017.

I get pretty much the same results.

Max 2016 time:208
Max 2017 time:419

Well, it wouldn’t be Max is we wouldn’t get a few of these thigs. Perhaps they complied the ‘debug’ version? :slight_smile:

Hope it gets fixed soon (if it can be fixed).

#7

there is a new MXSCallstackCaptureEnabled context which can be turned off. Running the loop with this context off, doesn’t help much, but in general this is a hint that some work has happened in the stack unwinding code. And i speculate that the scope entering/exiting in the loop body is affected by this …

#8

Yes, I tried it before posting, but didn’t notice any difference.

But, even if it would be the responsible of the slowdown, I couldn’t find a global switch (at least) to turn it off, meaning that you would need to run all your code within this context. I don’t think that is anything good, moreover if you have to modify all your previous code to work that way.

Performance of MXS was never too good, but I can’t think of any good reason that justify slow down the loops by 50%. It’s not a few milliseconds slower, it is literally half the speed.

#9

Of course i do not argue about this being a serious slowdown - just posting about a suspicion
Best way to get this things fixed is to report it ASAP - so please do so…

I can do the same…
And please post the public defect report number after reporting, this helps pushing such issues …

#10

I just came across this thread after finding my scripts running slower in 2017… has there been any more news from the devs on whether this will be fixed in any future service packs?
I’m sure I’m not going out on a limb to suggest this is a bit of a deal-breaker for many studios?

#11

I just checked and can confirm the problem remains in SP1.

#12

Yes - nothing in that regard has happened - maybe you can stress that on the other board a bit more :wink:

#13

could you check the performance for:


(
	count = 1000000
	t = timestamp()
	for k=1 to count do ()
	format "1 >> time:%
" (timestamp()-t)
)
(
	count = 1000000
	bits = #{1..count}
	t = timestamp()
	for k in bits do ()
	format "2 >> time:%
" (timestamp()-t)
)

please?

#14

Max 2016 SP3

1 >> time:189
OK
2 >> time:201
OK

Max 2017 SP1

1 >> time:345
OK
2 >> time:341
OK
#15

the same results… it’s bad. it’s more likely caused by new way of executing the mxs. i hoped that the reason was a new way of passing data.
that means we can’t solve on our own this slowdown issue.

#16

Devs said that they implemented improvements regarding code safety etc …

#17

Denis:

could you quickly come up with a real usecase where this slowdown gets in the way ? A thing people could run on an existing scene and see the slowdown at once ?

#18

There can’t be many scripts that don’t rely on looping. The simple fact an empty loop takes twice as long should be proof enough of a major issue shouldn’t it?

#19

No - as long as nobody can come up with real use case where this hurts performance in a realworld script i’m sceptical.
And “major issue” would be if this loop slowdown would have happened without the devs changing the relevant code. As i’ve written above, the devs refactored parts and introduced maxscript scope related safety checking code , which in turn increases stability.
The above code by Denis looses 140ms for 1 mio iterations, thats 0.14 microsecs or 140 Nanosecs per iteration. How many maxscript operations do you know that do not take several magnitudes longer ?

#20

Okay some silly code that might show that this is indeed an issue in realworld
and it gets worse with each outer loop iteration

(
	function calc a b=
	(
		result = 1 as float 

		af = a as float
		bf = b as float
		for i = a to b do
			result = random af bf
		result
	)


	a=1.5
	count = 1000
	t = timestamp()
	
	for j = 1 to 6 do
	(
		for k=1 to count*j do 
		( 
			a=  a* (calc 1 k) / (calc 1 k)
		)
		format "% >> time:%
" (count*j) (timestamp()-t)
	)
)

Max2016 SP3
1000 >> time:543
2000 >> time:3169
3000 >> time:9273
4000 >> time:20008
5000 >> time:36955
6000 >> time:61322
OK

vs.
Max2017 SP1
1000 >> time:960
2000 >> time:4690
3000 >> time:13216
4000 >> time:28614
5000 >> time:52909
6000 >> time:87669