On Oct 17, 6:05 am, André Adam <[email protected]> wrote: > Hi there, > > in general, are the Maya API(2) classes considered to be faster than > calling equivalent native Python classes? Like, using the MAngle class > for radian to degree conversion instead of Python's math.degree()? I > am calling that per frame, so performance is a factor here. > > Thanks in advance for any insight you can share! Cheers!
I agree with other advice in this thread: you need to profile to find out. If performance is really important you are going to want to do more than use the Python profiler too. In order to get a full picture of where the time is going you're also going to have get a look at what is happening in all the C/C++ code that the Python profiler can't look into. Beyond that, instrumenting profilers can be problematic. I'd suggest using an external sampling profiler in conjunction with the Python profiler. I've been using "Very Sleepy" with some success. Profiling is a bit of a black art, and trying to profile Python code running in Maya can get pretty tricky. I'd also suggest that you not worry about performance until you know that it is a problem, and not worry about the performance differences between approaches until you know that that's where your bottleneck lies. I would be surprised to find that the difference between using the MAngle class's method and the Python equivalent was the bottleneck in a practical application (though I have been known to be wrong ;) ). I've been working on a plug-in for Maya for... well, quite a while now. We developed the algorithms it uses in Python, outside of Maya, first in 2D using PyGame and then in 3D using visual. Our initial Python implementation was, literally, several thousand times slower than we needed. Then we moved to Maya, and re-implemented the plug-in in Python there (this is a bit different from the most usual use-case for Python in Maya in that we were implementing a plugin rather than writing scripts, fro the most part.) We made some changes that made things run a bit faster in Python, just so we could use the thing without pulling all of our hair out, but it was still painfully slow. Once we had things working we started rewriting the most expensive parts of it in highly optimized C, compiling that to a DLL, and calling it from Python using ctypes. And I made an interesting discovery: creating and destroying Maya API types (like MPoints and MVectors) in Python from the data produced by the C was as expensive as doing what we had moved to C had been in Python. In other words, having to translate the results from C into Python objects was as expensive as doing lots and lots of trig and vector math had been in Python. An awful lot of gory delving into Swig, pointers, machine representation of Maya objects, etc., ensued. It turns out that the CPython implementation (which is what is embedded in Maya) is very inefficient at creating and destroying objects. On the other hand CPython can be pretty quick at other things if you understand its quirks- you want to push things onto the C implementation as early as possible. Using things like map, and list comprehensions, over Python loops, just as an example, can make a dramatic difference. If you write Python code with that in mind the amount of garbage you create is going to absolutely dominate things like converting degrees to radians anyway (by garbage I mean objects that will have to be garbage collected.) I'm finding it hard to imagine a case in which a PyMel script is bottlenecked converting degrees to radians, and even harder to imagine a case in which the difference the MAngle methd and the Python math module's method is enough to remove the bottleneck. Anything I can imagine that fits that description should probably not be a Python script, or at least should call out to something written in C. You might object that your question is more general than converting between degrees and radians, but I would answer that optimization is, necessarily, about specifics. This is one reason you should avoid optimizing till you are sure you must. I don't believe that Maya does any GPGPU stuff at all, though I might be mistaken. The GPGPU world is just starting to mature to a point where it is reasonable to use it if you have to support a wide customer base, and it requires really rethinking the structure of your code to make good use of. We've looked at things like OpenCL for our product, and if it is successful I'm pretty sure we will eventually make use of it. But our decision so far has been to ignore it even though we are doing something that is pretty computationally expensive. At any rate, a lot of the places where Maya is slow are not really about doing vector math in a tight loop- they are architectural problems. Why are expression nodes so slow? I'm pretty sure that using the GPU can't solve that, for instance. Best T -- view archives: http://groups.google.com/group/python_inside_maya change your subscription settings: http://groups.google.com/group/python_inside_maya/subscribe
