maya.cmds vs pymel speed?
breeder
I did some test with maya.cmds as pymel , and result is that pymel is
slower.
For simple:
for i in xrange():setAttr
it is two times slower.
For expression i was testing it was 4-5 times slower that maya.cmds.
In my test i tried both "pymel.core.cmds" and PyNode method.
Is this "normal" thing for pymel to be slower that maya.cmds?
Thanks
"Sveinbjörn J. Tryggvason"
McKenzie(macaronikazoo.com) pymel is slower:
http://www.macaronikazoo.com/?p=271 and http://www.macaronikazoo.com/?
p=290
He has some excellent python related posts on his site btw.
-Sveinbjorn
Jo Jürgens
breeder
import pymel.core as pm
pm.setAttr("locator1.tx",5)
So , in this example , does pymel use maya.cmds or is actually
creating PyNode for "locator1" and than setting attribute???
Paul Molodowitch
Paul Molodowitch
Ofer Koren
code... right Paul?
- Ofer
www.mrbroken.com
breeder
easier.
But than ,this complex code is running slow.
Speed hit , at least for me is unacceptable.
I'm staying with maya.cmds untill(if possible) this speed problem is
resolved.
On Oct 3, 4:36 am, Ofer Koren <kor...@gmail.com> wrote:
> pymel is more about the speed of coding, less about the speed of the
> code... right Paul?
>
> - Oferwww.mrbroken.com
>
>
>
> On Sat, Oct 2, 2010 at 1:22 PM, Paul Molodowitch <elron...@gmail.com> wrote:
> > (err... that should have read 'area', not 'are'...)
> > - Paul
>
>
> >> For setAttr, it doesn't create a pynode... but the command is wrapped, so
> >> it will still be slower than the maya.cmds equivalent.
> >> In general, though, speed is one are where PyMel still has a lot of room
> >> for improvement...
> >> - Paul
Count Zer0
IMHO, the speed of coding in PyMEL FAR outweighs the lack of speed in
script execution. 99% of the time, script execution speed is near
instantaneous, so PyMEL is the proper thing to use.
When you get into lots of mesh iteration and weights stuff, you might
want to go back to maya.cmds or better yet get into Python API calls.
I think that stuff works even faster then MEL or maya.cmds, not as
fast as compiled API, of course.
Chad confirms this at the bottom of this thread:
http://forums.cgsociety.org/archive/index.php/t-833446.html
-jason
On Oct 2, 7:36 pm, Ofer Koren <kor...@gmail.com> wrote:
> pymel is more about the speed of coding, less about the speed of the
> code... right Paul?
>
> - Oferwww.mrbroken.com
>
>
>
>
>
>
>
> On Sat, Oct 2, 2010 at 1:22 PM, Paul Molodowitch <elron...@gmail.com> wrote:
> > (err... that should have read 'area', not 'are'...)
> > - Paul
>
>
> >> For setAttr, it doesn't create a pynode... but the command is wrapped, so
> >> it will still be slower than the maya.cmds equivalent.
> >> In general, though, speed is one are where PyMel still has a lot of room
> >> for improvement...
> >> - Paul
Paul Molodowitch
John Creson
you are doing.
Yes, there are things I can do to really slow down my scripts (lots
and lots of prints statements perhaps?), but if our scripts are
working efficiently, they will be using Maya to do the heavy lifting,
not the scripting.
Something that PyMEL has helped us accomplish, and has helped with a
specific known speed issue, is the ability to pass a selection as an
mObject, rather than converting it to a string, passing the string and
then converting back to an mObject. (kind of like the lots and lots of
prints statements above, only applied to how commands communicate
their results to the next command) This can be really important when
the names of the selections need to be really long because there are
many levels of hierarchy and the objects have been duplicated many
times.
Also, as suggested, taking advantage of python enabled API queries is
fast and safe, and PyMEL has built this into normal scripting
situations. You don't have to do anything special to take advantage
of this other than use PyMEL, API opportunities are built in. (and
it's a great place to look to see how it's done, in case you'd like to
work out how to make things faster in this way)
Along the lines of passing strings into commands...
The example is doing just that:
pm.setAttr("locator1.tx",5)
whereas, if you built the locator in your script, assigining it to a
variable, and then set that attr using the variable, then you should
avoid needing to convert the string to the mObject.
myL = pm.spaceLocator()
pm.setAttr(myL.tz,5)
Also, perhaps you are also seeing the time it takes to do the first
part in the example:
import pymel.core as pm
It takes a little time to import pymel. It's doing a lot. It should
not be factored into performance tests.
This part is done once in Maya(like starting Maya), and could be put
into your userSetup.py to make it more invisible.
If you use PyMEL, you don't tend to use it as a one-off here and
there, you tend to work with it to accomplish a major task, or in a
series of inter-working tools. The more you use it, the more
opportunities it has to save you time at runtime, as well as during
development.
-JohnCreson
mtherrell
PyMel rant: Pymel allows for more concise, less terse (efficient yet legible) code. It allows faster turn around
time on more complex problem solving by a majority of people, (with the exception of a few clerical savants out
there who have wrote-memorized the entirety of mel). It gives standardized OOP "dot" notation access,
simultaneously, to both the mel commands layer and API via its well organized, well conformed methods and attributes
belonging to PyNodes. This reduces having to remember or research the large variety of argument structure and
command names that have accumulated in both mel and the Maya API over the years. (too bad those were not designed
that way to begin with, and that stuck with.. ok remember that for the next big tool).
Pymel is not a toy, and is used for serious studio pipeline by big boys and girls. It does have an irrelevant
trade-off in speed vs. cmds, (some folks can't see past that unfortunately, particularly the clerical savants)..
nevertheless, PyMel can often be written to be faster than its cmds counterpart when using the API access that it
possesses. Ultimately, the eval speed of Pymel vs cmds is a moot point, because it is more than adequate, even at its
slowest, for its targeted use-cases, added to the time saved in code-comprehension by new comers to the pipeline,
and iteration time improving or inventing new pipeline. O.K. rant over.
damon shelton
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/d6809362-bdf7-4e36-ae08-295bda5bc8bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Justin Israel
This is a 7 year old thread.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAM9RXo%2BEHY0RV5whw0X4%3DGSco6JAJ%2Bu53dJsoLx_oJh_dDTygQ%40mail.gmail.com.
Simon Payne
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2gJ4RXpD_Q%2BP7uuF5yA6S9FDWve-Eg_duXfDDfLP-VYQ%40mail.gmail.com.
Marcus Ottosson
This is a 7 year old thread.
Sometimes it takes time to find the right words.