Yeah of course, but this doesn’t make “everything is wrong”. I could have just avoided all the trouble by just writing half lines of code like you did in your last example.
At the end of the day though, both my “bad” code and your “good” code, are proving the same thing. That it’s faster to create the pointer once.
ok… not everything.
but i have no idea why you include in the measuring sample turbosmooth (which doesn’t make sense because your loop is just for number of baseobject verts), why you add edit_normals which doesn’t work, and why you create a new node every time.
it doesn’t matter for the thing that you measure how many vertices the mesh has, what kind of modifiers in the stack before edit_normals, and how many nodes tested…
- turbosmooth was because I wanted to call the function more times (the baseobject as I’ve said a couple times already, was a mistake because in a previous test I was using a collapsed stack, but I’ll say it one more time… it was a mistake! )
- it happen to use edit_normals because that was the example from the documentation, so I just used the same modifier, I didn’t care if it was working, I just wanted to see how faster it was to call the same function using the two different ways. (yeah, I could have just avoided all this trouble by doing something like your previous example, but at that point I was stacked on the documentation example)
- I don’t remember what I was thinking for creating a new node every time… hahah
- Yeah, I know, it was part of my messy experimenting and I was excited because it seemed very strange to me that I don’t see people using this method so I wanted to share it. I didn’t tried to optimize my code because that wasn’t the point. I think that we shouldn’t stick to my messy test code, we should stick that there is a great performance gain with the second method.
Does this also work with other functions such as polyop.getVert?
(I’m on my phone so I can’t test it.)
it works for most of interfaces. but the difference can vary. it depends on how long it takes to create an interface. so it might not be dramatically faster but it saves the memory for sure.
here is a samples:
delete objects
p = converttopoly (box())
m = converttomesh (box())
gc()
num = 10000
(
t1 = timestamp()
m1 = heapfree
for k=1 to num do polyop.getvert p 1
format "polyop 0 >> time:% memory:%
" (timestamp() - t1) (m1 - heapfree)
pvert = polyop.getvert
t1 = timestamp()
m1 = heapfree
for k=1 to num do pvert p 1
format "polyop 1 >> time:% memory:%
" (timestamp() - t1) (m1 - heapfree)
t1 = timestamp()
m1 = heapfree
for k=1 to num do meshop.getvert m 1
format "meshop 0 >> time:% memory:%
" (timestamp() - t1) (m1 - heapfree)
mvert = meshop.getvert
t1 = timestamp()
m1 = heapfree
for k=1 to num do mvert m 1
format "meshop 1 >> time:% memory:%
" (timestamp() - t1) (m1 - heapfree)
t1 = timestamp()
m1 = heapfree
for k=1 to num do getvert m 1
format "meshop 2 >> time:% memory:%
" (timestamp() - t1) (m1 - heapfree)
)
Hey Denis, I’m just curious, what interface takes the longest to create in 3dsmax?
well… it’s hard to remember all of them. if you develop a tool that really needs a good performance or expects intensive memory use if have to check this things and try different tricks…
but usually the interfaces that work only in opened modifier panel can be well optimized with using a point to there methods… edit_normals, unwrap_uvw, skinops…
ok… i’ve understood. it was just a succession of random coincidences