Hah, yes I got your joke, but thought you might have some maxscript ninja manouvres to workaround the shortcomings of my code
i don’t remember where but i saw the using of MXSCallstackCaptureEnabled as a Sticky Context
i don’t have max 2017 and can’t try if but in case of the context is sticky you can set it ON and OFF as:
set MXSCallstackCaptureEnabled on
set MXSCallstackCaptureEnabled off
if it works the version universal code could be:
global CallstackCapture
(
struct CallstackCaptureStruct
(
private
_canset = (maxVersion())[1] / 1000 > 18,
public
fn canSet = _canset,
fn enable = if _canset do execute "set MXSCallstackCaptureEnabled on",
fn disable = if _canset do execute "set MXSCallstackCaptureEnabled off"
)
CallstackCapture = CallstackCaptureStruct()
ok
)
-- CallstackCapture.canSet()
-- CallstackCapture.enable()
-- CallstackCapture.disable()
Hah, your ninja skills know no bounds. That is a nice workaround indeed!
Thanks again Denis.
It doesn’t crash in 2016, that’s for sure. I haven’t run any benchmarks though.
does it work for 2017? i don’t see in mxs 2017 help anything that this context can be used sticky. It was only my guess that it cab be sticky
there shouldn’t be any slowdown using this struct because it makes sense to set it before an execution of a ‘massive’ part of code
Confirmed 4x faster using this code on 1000 iterations of failed try()catch()
Without MXSCallstackCaptureEnabled
time:162 heap:1272208L
and with :
time:44 heap:1149124L
But yes, a pretty rare use case. Apologies for hijacking this thread!
actually it’s interesting to know the difference between enabled vs disabled using of the CallstackCapture. how difference the time and memory usage?
Here you go :
3dsmax 2016
CallstackCapture enabled : time:28ms heap:1144928L
CallstackCapture disabled : time:30ms heap:1144872L
3dsmax 2017
CallstackCapture enabled : time:173ms heap:1288826L
CallstackCapture disabled : time:42ms heap:1164850L
code used : (in case I’m messing the test up)
global CallstackCapture
(
gc()
struct CallstackCaptureStruct
(
private
_canset = (maxVersion())[1] / 1000 > 18,
public
fn canSet = _canset,
fn enable = if _canset do execute "set MXSCallstackCaptureEnabled on",
fn disable = if _canset do execute "set MXSCallstackCaptureEnabled off"
)
CallstackCapture = CallstackCaptureStruct()
ok
t = timestamp()
h = heapfree
count = 1000
for k = 1 to count do (try(execute "test 123")catch())
format "3dsmax 20%
CallstackCapture enabled : time:%ms heap:%
" (((maxVersion())[1] / 1000)-2) (timestamp() - t) (h - heapfree)
gc()
CallstackCapture.disable()
t = timestamp()
h = heapfree
count = 1000
for k = 1 to count do (try(execute "test 123")catch())
format "CallstackCapture disabled : time:%ms heap:%
" (((maxVersion())[1] / 1000)-2) (timestamp() - t) (h - heapfree)
CallstackCapture.enable()
)
it’s very interesting to see when this ‘CallstackCapture’ feature works well VS any previous version (2016 for example).
as i can see from the test results above this feature makes both performance and memory usage worse.
Decided to try this with the new service pack, didn’t really expect it would get much better… but didn’t really expect it would get that much worse:
Max 2016: time:696 ram:248L
Max 2017 SP1: time:8734 ram:264L
Max 2017 SP2: time:14630 ram:272L
Same increase with few of the other code snippets here, is it just me… or what the hell is going on?
SP2 Is only about 10% slower here
Max 2016 SP3: time:268 ram:248L
Max 2017 SP1 time: 9744 ram:1784L
Max 2017 SP2 time: 10894 ram:552L
Just did a few tests on Max 2017 SP2 and nothing was fixed regarding this terrible stability implementation added to MXS (bug in plain english).
But the results are not as bad on my end as in your tests. In fact, some seems to be a little bit faster in SP2.
Code from Post #48
3DS MAX 2011
time:1429ms heap:3471592L RAM:1138.97MB
3DS MAX 2014
time:1360ms heap:3460208L RAM:1147.47MB
3DS MAX 2016
time:1312ms heap:3499760L RAM:1139.0MB
3DS MAX 2017 – SP1
time:5015ms heap:3704136L RAM:1138.08MB
3DS MAX 2017 – SP2
time:5000ms heap:3696432L RAM:1142.81MB
Code from Post #56
MAX 2016
time:261 ram:663624L
MAX 2017 – SP1
time:6540 ram:680204L
MAX 2017 – SP2
time:6033 ram:680204L
Code from Post #68
MAX 2016
time:55 ram:216L count:1
time:59 ram:216L count:10
time:102 ram:216L count:100
time:528 ram:216L count:1000
time:4864 ram:216L count:10000
MAX 2017 – SP1
time:90 ram:196L count:1 >> 1.63 slower
time:197 ram:196L count:10 >> 3.34 slower
time:1231 ram:196L count:100 >> 12.1 slower
time:11607 ram:196L count:1000 >> 22.0 slower
time:115296 ram:204L count:10000 >> 23.7 slower
MAX 2017 – SP2
time:101 ram:196L count:1
time:215 ram:196L count:10
time:1299 ram:196L count:100
time:12055 ram:196L count:1000
time:121154 ram:196L count:10000
Code from Post #69
MAX 2016
time:47
MAX 2017 – SP1
time:1293
MAX 2017 – SP2
time:1222