> Hmm, a git-grep didn't bring up to much info related to 2011, but > perhaps I should be a little more patient and just wait until 2011 has > been released :) - not too long to go.
first of all, i really don't think i let 2011 slip in the docs, and i am glad your git-grep didn't find anything. but now that the cat is out of the bag, let's talk: Performance pymel is largely fleshed out so it's a good time to start focusing more on performance. it's great timing because now that we have autodesk on board, we can begin to ask them for features to improve pymel's performance. pymel bridges the api and maya.cmds, which can unfortunately sometimes be an expensive place to be. for example, when a PyNode is instantiated with a string, we have to use that to get an api object. then when that node is used in a maya.cmds function, we must convert the api object back to a string. this has to be done on every call because we have no indicator if an object's name has changed since the last call. we could perhaps improve performance by getting autodesk to support passing api objects into maya.cmds functions. we toyed with this in maya 2009, but it was removed last minute. we hope revisit this topic for the next release. the last we talked about it, selection sets were looking like the object of choice for passing into maya.cmds functions. another hope in this regard was to rewrite ls, listRelatives, and listConnections using maya.OpenMaya so as to avoid string->api object conversions, but it's a massive undertaking (already begun by Olivier), and there's no guarantee of a performance boost. it could end up being even slower. every time you cross the python/C++ boundary, you take a performance hit. currently when you call cmds.lst, cmds.listRelatives, etc, C++ is doing all computations, and swig converts the result to python once. the major performance hit is string to api conversion done in python by pymel. if we rewrite these commands usng maya.OpenMaya everything will be done in python, with swig marshalling between python and C++ with every api call, which is not terribly efficient, but we save on the string processing. byron, i see the performance tests you've started making on your github fork. i think this is a very good idea. i'd love if the tests could include side-by-side comparisons of maya.cmds, pymel.core, and maya.OpenMaya. API i also think there is a lot of room for improvement and new utilities in pymel.api. we've done a lot of work with the API just to make pymel work, but not all of it is exposed. we've already created a really easy way to create api commands on the fly without needing to create a plugin file, this needs to be extended to nodes, translators, locators, etc. in addition, we've added support for python AETemplates and we have a way to add custom methods to your own custom nodes. we need to combine all of this into a unified workflow. PyQT now that the gui in maya 2011 is based on Qt, there is an immediate need for a good set of utilities for working with these objects. the first that comes to mind is a pyqt version of lsUI that actually works. i've yet to dig very deep here unfortunately, but i'm open to ideas. i've used PyQt pretty extensively, but i'm not sure what specific issues we'll see where PyQt and PyMEL meet. those are my thoughts at the moment. -chad -- http://groups.google.com/group/python_inside_maya
