Matrix Mage

Thanks for the clarification! I’ll give it a try.

Hi,

I am trying to decide whether reusable APEX rig modules should be implemented with native APEX nodes or with a single RunVex node.

For example, I have a small module with two inputs:

axis: Vector3
xform: Matrix4

It transforms the axis as a direction vector and then normalizes the result. The native implementation uses several APEX nodes for vector conversion, matrix multiplication, and normalization. The RunVex implementation performs the same calculation in a short VEX snippet.

The module will be saved as an APEX subgraph and instantiated many times inside a larger rig graph, so I would like to understand the compilation behavior rather than only compare the evaluation time.

My main questions are:

Does a RunVex node introduce an additional VEX compilation stage on top of the normal APEX graph compilation?
When is the RunVex snippet compiled?
Once per unique snippet?
Once per RunVex node instance?
Once per subgraph type?
Once per parent APEX graph compilation?
Or every time the graph is loaded or recompiled?
If the same RunVex-based subgraph is instantiated many times in one parent graph, is the compiled VEX program shared by all instances, or does each instance incur its own compilation cost?
Does RunVex use Houdini’s normal VEX specialized-code cache? If so, what exactly is used as the cache key?
When Force Reload Graph is enabled on an APEX Invoke Graph SOP, the documentation says that the APEX graph is reloaded and recompiled. Does this also force the RunVex VEX snippet to be recompiled, or can RunVex still reuse cached VEX code?
Is the compiled VEX program stored or reused when a RunVex module is saved as an APEX subgraph, or is the subgraph only storing the snippet source and port definitions?
Is there an official profiling method or API that can separately measure:
APEX graph compilation time;
RunVex/VEX compilation time;
graph evaluation time?

I can measure the total cook time of an APEX Invoke Graph SOP with hou.OpNode.lastCookTime() or the Performance Monitor. I can also compare:

Force Reload Graph ON:
graph reload + compilation + evaluation

Force Reload Graph OFF:
normal cached evaluation

and use the difference as an approximate compilation-related cost. However, I am not sure whether this method measures an actual cold RunVex compilation or only an APEX recompilation with a VEX cache hit.

My practical goal is to choose the best implementation strategy for frequently reused rig modules. I need to compare both:

first-load/graph-compilation cost;
steady-state evaluation cost when the compiled graph is invoked many times.

Any clarification about the internal compilation and caching behavior of RunVex would be greatly appreciated.