::more thoughts on pymel::

July 19th, 2010 by hamish download the zooToolBox

So after using pymel for a bunch I’m done with it.  Why you ask?

For starters its kinda this weird middle ground where its not mel (maya.cmds) and its not the api.  You can’t easily mix it with maya.cmds without having to throw in explicit str() casts all over your code, and to put isinstance( obj, PyNode ) checks everywhere which is messy and error prone.  You also can’t easily mix it with the api directly.

So you’re kinda left in this unusual grey zone.  PyNode objects do carry along with them some handles to API objects like their mobject and others depending on the PyNode in question, but again, you have to speckle you code with attribute references like someNode.__apiobject__ etc, if you want to call into anything inside maya.OpenMaya.

But most importantly, it is amazingly slow.  Like mind bogglingly slow when compared to mel. Exactly whats going on I haven’t spent the time to discover, but here is a very simple, albeit contrived demonstration of its tardiness.

import time
import maya.cmds as cmd
MAX = 1000
start = time.clock()
for n in xrange( MAX ):
print 'time taken %0.3f' % (time.clock()-start)

from pymel.core import ls
start = time.clock()
for n in xrange( MAX ):
	ls()  #NOTE: this is using pymel’s wrapping of the ls command
print 'time taken %0.3f' % (time.clock()-start)

On my machine the first test which uses just mel takes 0.07 seconds on a completely empty scene. The second test, which uses pymel, takes a whopping 24 seconds.

That is a 350x speed difference. That’s HUGE!

Now, originally when I started writing this blog post I hadn’t done the speed tests. My assumption was that it was slower, but the slow down was probably merely a factor of 2 due to the way pymel has to cast return values from strings, back to MObjects. But I figured instead of writing the blog post with assumptions in it, I should at least do the work to get some actual numbers.

The question now becomes, do the benefits of pymel outweigh the negatives?  In my case I believe the answer is a resounding NO.

So after using it for as long as I have I’m kinda backpedaling. Its going to suck pulling pymel out of the tree, but clearly it has to be done. I’ve written a heap of rigging code using it, and have been wondering why it has been running so slow. My assumption was that it was my fault, and that somewhere I was writing some super redundant code. Now I know better.

This is a pretty big shame – I like what I gain from pymel, but I don’t like the constraints it puts on me, and the speed hit is unacceptable.

I do however, have some ideas on what might be a better solution to wrapping mel in a nicer way. It seems to me that extending the MObject class and making it really easy to cast strings to MObject instances would be a cool way to go. The wrapped objects would be native MObjects, so they’d be first class API citizens, and you could cast them to strings easily to pass back to mel should you need to. I’ve done some tests on the idea and so far it seems promising. I have a feeling I won’t ever have a solution as comprehensive as pymel, but at the same time I’m not sure thats what I want anyway.

Anyway, I just wanted to put my findings out there for anyone else who was shopping around for opinions on whether to use pymel or not. Consider yourself warned.


This post is public domain

This entry was posted on Monday, July 19th, 2010 at 11:31 and is filed under main. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • John
  • hamish

    Oh nice, hardly surprising that I’m late to the party. ;) although he doesn’t really break down whats going on… I couldn’t help myself and have spent some time investigating further. I’ll put my findings into another blog post methinks.

  • http://goodsoul.de eRiC

    he hamish! A friend is currently building MayaRV http://packages.python.org/MRV/
    I think he built it from ground with speed in mind. The whole doc is a little gobbledegook to me. But I think you gonna dig it. ;] Currently I didn’t, but I need to check it out as well!

  • Byron

    Before you rewrite PyMel in your own flavor, your might want to have a look at MRV:

    There is also quite an interesting comparison to pymel:

    PS: I am the author of MRV, but the reason I wrote it is that I was somewhat at the same spot as you are now, two years ago though.

  • hamish

    Hey Byron! A friend of mine did bring my attention to mrv just a few days ago. I haven’t had a chance to look but I will take a look. Thanks for the heads up!

  • Chad Dombrova

    what version of pymel are you using? running the same code I get:

    time taken 0.186time taken 4.561

    certainly not amzing, but it’s far from 350x

  • Anonymous

    G’day there Chad!
    I’m not sure what version this was using (I should have taken note and put it in the post) but this post was written almost 2 years ago now.  So whatever version was current as of mid 2010, thats the version I was using.

    I guess the broader point is that you either need to use 100% pymel or 0%.  Using some pymel is dangerous, unless you’re writing leafy code.