Python causes maya to run very slowly

I’m in the process of setting up scripts for our pipeline, (which I’ve done in the past). I would like to use python to access our database, prompt the user for input if needed, setup environment variables, and launch Maya.

All of this works fine except that when I launch Maya from within my python script (regardless of method, ie… subprocess, os.system, call, etc…) Maya will take much longer to simply launch… then all work done within maya suffers from massive slowdowns. Especially things like scrubbing the timeline with a skinned character in the scene (even if the rig is very lite) causes Maya to slow to the point that its unusable.

In contrast and as a way around this, I’ve made a .bat file to essentially do the same thing, and this has no slow down.

I’d like to move back to a python solution if possible since it will afford me more options (not to mention bat file syntax is terrible)
I’ve had setups like this in the past with python 2.6 and previous versions of Maya, and never had issues like this… Any insight?

I have reinstalled Maya, and python.
I have tried other 2.7.x releases of python
I want to stick with 2.7 since Maya 2014 uses 2.7.3 and this “should” encourage compatibility with other libraries

Thank you for any input.

Windows 7 x64
Python 2.7.6 amd64
Maya 2014x64 SP3

Are you trying to process the results of the call/subprocess/etc? From my 2.7.3


os.system(r'"C:\Program Files\Autodesk\Maya2011\bin\maya.exe"')

shows no difference between that and any kind of shell launch. I don’t think Maya could even know how you’ve launched it if that’s all you’re doing. This isn’t related to scripts running inside maya at startup, is it?

[QUOTE=Theodox;23742]Are you trying to process the results of the call/subprocess/etc? From my 2.7.3


os.system(r'"C:\Program Files\Autodesk\Maya2011\bin\maya.exe"')

shows no difference between that and any kind of shell launch. I don’t think Maya could even know how you’ve launched it if that’s all you’re doing. This isn’t related to scripts running inside maya at startup, is it?[/QUOTE]

Nope, not processing any output… just setting variables and launching the maya exe… I know it shouldn’t cause slow downs, and like I said in the past (different hardware and software) it didn’t … but now it is.

Just did a test:
open cmd prompt and type “maya”
Time for viewport (opengl 3D grid) to become visible 7 sec
Time for all default startup scripts to run 11 sec

in same prompt start a python interpreter

os.system(‘maya’)
Time for viewport (opengl 3D grid) to become visible 40 sec
Time for all default startup scripts to run 60 sec

Ran the same process on another machine… only hw/sw difference is it doesn’t have maya SP3.
That machine does not have the same speed issue, both methods run just as fast.

Nothing else in my list of installed apps should have any effect on this.

There is also another issue with my python setup that doesn’t affect the other machine.
If I open a python cmd window I can only input 10 lines before the window will crash and close.
The lines can even be empty (ie simply start the interp and press enter 10 times) and it will crash

The only way around this is to use another interp, like within maya(script editor) or pycharm (in run/debug mode)…
Although the run/debug interp works in pycharm the simple terminal within pycharm will also crash.

I’m stumped.

Have you tried doing a fresh python install? Or at least creating a virtual env with no additional libs or sitecustomize?

[QUOTE=capper;23746]Have you tried doing a fresh python install? Or at least creating a virtual env with no additional libs or sitecustomize?[/QUOTE]

This is a fresh machine, and I’ve tried a reinstall of python… The only python libraries I’m using are psycopg2 for connecting to my postgres database, and pyside for gui, however those libraries aren’t installed on my machine (my python27/Lib/site-packages/ is empty). So a fresh python interp as in my example above doesn’t load them.

I keep all my python libs and dependencies in a folder within my pipeline’s module folder /pipeline/deps
sys.path.append must be used to make them accessible to the interp (which is part of what my startup script is for).

It definitely sounds like a bad python install. Try putting a drop of PortablePython on a memory stick and running the same thing . I bet you wont see the problem.

As a temporary workaround you can just use the mayaPy interpreter - it works fine as a regular python interpreter, so where you would ordinarily call python.exe just call mayapy.exe.

[QUOTE=Theodox;23748]It definitely sounds like a bad python install. Try putting a drop of PortablePython on a memory stick and running the same thing . I bet you wont see the problem.

As a temporary workaround you can just use the mayaPy interpreter - it works fine as a regular python interpreter, so where you would ordinarily call python.exe just call mayapy.exe.[/QUOTE]

So…
I’ve tried Portable python (v2.7.5.1) on a usb drive and it works fine, and both of my errors go away…
I’ve uninstalled and reinstalled python 2.7.6x64… Same problems exist
I’ve installed python2.7.3x64 (same version as used in maya-albeit they use a custom version)… Same problems as with 2.7.6
I’ve installed 2.5.4x64 And problems are gone.
If I use the version of python distributed within my Nuke8 install folder (2.7.3) Problems are gone

And it gets weirder…
After a full uninstall of python I copied the portable python version off the thumb drive into the folder C:\Python27… run python.exe from there and the same problems exist, even though this ran fine on the thumb drive!!!
I renamed the folder to Python26, run python.exe And all problems went away.
I named it back to Python27 Problems come back
Move the folder to my 2nd partition D:\Python27 Problems go away

It would seem that windows has a problem with the path C:\Python27… registry entry???
So as of now I have reinstalled 2.7.6 but chose c:\Python instead of c:\Python27 as the install folder, and its working.
I’d still be interested in hearing a solution to this if anyone has one.

Thanks.

Portable doesn’t use registry settings, but you should see if you have a PYTHONPATH or other environment variable that’s pointing somewhere odd. In particular maybe something is pointing at the Nuke folder and kicking off an auto-import of something Nuke-related that takes a long time to start