Many thanks for the thorough explanation, that was quite some insight! Oh, and sure, my question was aimed for a general answer and not necessarily bound to the rad/deg conversions. :)
Thanks again, cheers! -André On Oct 21, 12:42 am, "T. D. Smith" <[email protected]> wrote: > 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
