There are various approaches to creating new operators. This section describes how the same SOP can be written in 6 different ways.

HOM/SOP_HOMWave.py
Uses pure Python to implement a simple SOP that runs a sin() wave through geometry.
HOM/SOP_HOMWaveNumpy.py
Uses pure Python with the numpy module to implement a faster version of the same SOP that modifies all point positions in a batch.
HOM/SOP_HOMWaveInlinecpp.py
Uses Python with embedded C+ code to implement the same SOP. The C++ code that is automatically compiled, linked, loaded, and run all from Python.
HOM/SOP_HOMWave.C and HOM/SOP_HOMWave.h
Uses C++ and the HOM API to implement the same SOP.
SOP/SOP_CPPWave.C and SOP/SOP_CPPWave.h
Uses C++ to implement the same SOP, but by accessing the data directly (rather than translating the data through the HOM API).
SOP/SOP_VEXWave.vfl
Uses VEX to implement the same SOP.

Each of the 6 different approaches has advantages and disadvantages.

Performance

The following table lists approximate relative timings for the different implementations of the SOP:

Test	Time
HOM/SOP_HOMWave.py	11400ms
HOM/SOP_HOMWave.C	1070ms
HOM/SOP_HOMWaveNumpy.py	420ms
HOM/SOP_HOMWaveInlinecpp.py	275ms
SOP/SOP_CPPWave.C	275ms
SOP/SOP_VEXWave.vfl	245ms

Notice that SOP/SOP_CPPWave.C, HOM/SOP_HOMWaveInlinecpp.py, and SOP/SOP_VEXWave.vfl run with close to the same performance. VEX can achieve similar performance as C++ primarily due to the fact that it is able to provide the following optimizations automatically:

Threaded evaluation (VEX SOPs can be multi-threaded automatically)
Optimized use of SSE, Altivec or other vector instruction sets
Run-time optimization based on the input parameters

HOM/SOP_HOMWaveNumpy.py is significantly faster than the HOM/SOP_HOMWave.py pure Python implementation because of the overhead of looping through all the points inside a Python loop.

HOM/SOP_HOMWave.py is slower than the C++ and VEX versions because it must continually allocate and deallocate HOM_Point objects as it iterates across points.

Maintenance

With regards to maintenance, the hands down winners are the VEX and Python implementations of the SOP. Since VEX and Python are scripting languages, the source is considerably shorter and doesn't require re-building between versions. It's marginally easier to create a VEX SOP since you can build an HDA directly from the command line (or graphically using VOPs).

Note the C++ code in the inlinecpp implementation is easier to maintain than the pure C++ implementation because:

You can use the Type Properties dialog to manage the parameter interface instead of C++ PRM_Templates.
You can use Python to implement all but the slow portions of the code.
Houdini compiles the code for you automatically.
You can change the code without having to restart Houdini.
If write code that would crash Houdini, inlinecpp often intercepts the crash and displays the stack trace in the node's error message (as long as you set catch_crashes=True or debug=True).

Ease Of Use

Though VEX is fairly easy to use, VEX is designed around algorithms that apply across many elements simultaneously. This makes it very good and efficient at running over all points or primitives, but less effective if you have a very serial algorithm.

Writing a SOP in Python opens up the SOP to use any of the myriad modules which are available in Python. Sometimes, the flexibility in writing an operator in Python will outweigh the performance penalty.

Importing geometry from an XML file description
Transferring geometry over a network connection
Deforming geometry based on a USB or joystick interface

By profiling your Python SOP with Python's cProfile module you can identify the slow portions and use the inlinecpp module to rewrite those portions in C++. As well, you can perform geometry operations not accessible from HOM by using inlinecpp to access the larger C++ HDK API.