Thanks for your elaborate reply ! About Performance: If you do serious benchmarking of OpenMaya, you will find that it is quite hard to make it work faster than the respective MEL commands, especially when complex filters are to be used. Without complex filters though, listing nodes using the API tends to be lighting fast - even in python - but the wrapping of the API objects will considerably slow it down. Major bottlenecks are MFn<something>.setObject() and MDagPath.node() in the sense that these operations are just very slow. This might be a fixable maya.OpenMaya issue though. When converting a whole bunch of node name strings to MObjects, it would be great to have a addMultiple method in the MSelectionList class - currently one has to make single calls to add() which is expensive. Converting from strings to APIObjects would only be done rarely if PyMel would operate on the API exclusively though, and a multi-add method would not be required in that case.
This is the essence of my findings, in case you are able to communicate this to Autodesk. PyQT This is something I am very interested in as well, can't wait to get a first trial of maya 2011 to see it with my own eyes. My personal opinion about the current state of PyMel is the following: - The memory footprint is too high - Startup times are too high - Its too slow in all areas that I have tested so far. - unittests seem like an afterthought, the unittest framework appears to be inconvenient in daily use, yet again, it takes too long to startup. When I run the tests myself ( maya 2008 ), I have many of them failing until the whole nose test run fails (inside of nose). - The testing framework does not appear to have a way to easily specify which maya version to run on. This makes it hard for you not to break things for older maya releases if you can only focus on the latest maya version. - I do not believe that developing PyMel in a test-driven fashion is feasible with the current test system, so it might not actually be done by all developers, which facilitates the introduction of bugs. PyMel needs to become more reliable which can only be achieved by TDD or similar development techniques. I totally consider that my experiences can be based on an incorrectly setup development environment or other influences which are not related to PyMel, hence my statements might be wrong. They are not meant to disregard the authors of PyMel or PyMel itself in any way. Kind Regards, Sebastian On Mar 13, 11:36 pm, Chad Dombrova <[email protected]> wrote: > > 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
