Hey Cameron,

There are a few things to consider with your workflow:

• For the UDOC, make sure you have the EXE compiled as a Windows Application and not a Console Application.  Each time the MF updates, the UDOC is executed and GUI I/O such as displaying the command window is expensive.
• Launching a Standalone Application via Python is probably taking the most time for each cycle.  The typical connection between a Standalone Application and the ZOS-API is 10’s of seconds.  
• Depending on how you’re communicating between C# & Python, you could run into a handful of issues:
  • If you’re calling python via exec(), then Python is launched on a new thread and there is no communication between your C# UDOC and Python.  You’ll have to “guess” at when Python is done, most likely by querying an output file from Python (this is an expensive operation)
  • If you’re using IronPython, then you’re limited in the set of Python modules you can use within your script.  No modules with compiled code (such as numpy or matplotlib) can be used with PythonNet (I suggest MathNET for numeric calculations and ScottPlot for graphing, both available via nuget).  The advantage of IronPython is you don’t need Python installed on the target machine.
  • If you’re using PythonNET and with using (Py.GIL()), you lose all multi-threading capability.  Although the MF sequentially updates each operand individually, a single operand can be evaluated with multiple threads.

So, although it is a “cool experiment” to get Python running from C#, you will never see the performance you’re expecting with a UDOC.  I would suggest converting all your code to C#.  Another benefit of the UDOC is if it’s compiled correctly, you only need 1 EXE file and this 1 file is stored in any ZAR if the UDOC is loaded in the MF.  This makes a pure C# UDOC extremely transferable between users.

Also, this is a great time to remind Zemax Engineers and Developers that UDOCs are still called an a executable and not on the same process as OpticStudio itself.  This makes UDOCs much slower than built-in operands.  Zemax should implement in-process UDOCs to really help expand the ZOS-API’s capabilities.