Performance comparison VEX vs Hscript

[magneto]

Is it possible to measure the performance difference of 2 operators, one written with VEX and one with using other operators and expressions?

I know VEX should be much faster but I get 2 different results.

When I use the operators on a box with 1M polygons, VEX is way more interactive, so definitely much faster in use.

The custom operator built with expressions is way slower.

But when I middle click on each OP, VEX shows 14 ms cook time, the other one shows 0.11 ms cook time. Isn't cook time is basically the evaluation time?

Do VOPs also include the compile time in cook times? If so, aren't VOPs compiled only once? For instance when you use the Mountain SOP which is VEX, there is no compilation ever, right? I am not sure when this happens. I thought it only happened when you actually changed VEX code and compiled it, but after that, there is no more compile ever.

[hopbin9]

But when I middle click on each OP, VEX shows 14 ms cook time, the other one shows 0.11 ms cook time. Isn't cook time is basically the evaluation time?

Cook time in that example might be cached results.

Try opening the performance monitor.

p.s. VEX compiles to native code. It will run as fast as C which is the fastest (excluding multi-threading issues). While VEX is fast, it's still can be slowed down by human error.

[graham]

The cook time seen when you MMB on subnet type nodes does not reflect the amount of time it took for all the child nodes of that node to cook. You'll need to use the performance monitor to get the totally cook time.

[magneto]

Thanks guys.

@hopbin, I don't think it's by me, because I even tried a very simple case where I do this:

P.x *= 0.2;

and that was still showing similar results in cook time.

@graham, I didn't know it didn't account all the time it took for child nodes. Because it's very clear when I change the value, the result comes noticably after the value is already set.

The interactivity of the VEX operator is awesome though which is what counts most.

I will try the performance monitor today to get a more accurate reading.

[eetu]

p.s. VEX compiles to native code. It will run as fast as C which is the fastest (excluding multi-threading issues). While VEX is fast, it's still can be slowed down by human error.

VEX does not compile to native code. It's compiled into bytecode, which is then run in a virtual machine.

This is all detailed very nicely in Mark Elendt's chapter in Production Rendering: http://www.amazon.com/gp/reader/1852338210

[hopbin9]

VEX does not compile to native code. It's compiled into bytecode, which is then run in a virtual machine.

This is all detailed very nicely in Mark Elendt's chapter in Production Rendering: http://www.amazon.co...ader/1852338210

Thanks, I was under the impression it was run native.