You forgot to rename the _dev_ to _d_ in your debug function. That will 
probably crash. Also there is a loose debug print statement in line 124 that 
will be executed as an import side-effect. 



On Jul 11, 2012, at 3:07 PM, Jonas Avrin <tradigi...@gmail.com> wrote:

> I posted reply to author but I can't see it so here is the link to the 
> working script if anyone at all is interested:
> 
> http://pastebin.com/T3iuf2gn
> 
> On Wednesday, July 11, 2012 5:21:52 PM UTC-4, Justin Israel wrote:
> That env dictionary wasn't really a significant memory overhead as it was 
> pretty small in terms of data. It just takes a lot of time to perform the 
> mel.eval() for every single one. If you really needed that complete data 
> structure, I would recommend that you cache it once, and then returned the 
> cached version on subsequent calls. That way you are reusing the original 
> dictionary each time. 
> 
> The del() command is good if you really do need to free a large persistant 
> data structure (not one that will get cleaned up in garbage collection).
> 
> Yea I am not hugely picky about naming as long as they are descriptive and 
> you can easily read the intent of each line. But it does get confusing when 
> people use the builtin names, such as how yours still shadows the 'range' 
> function.
> 
> Also, in your debug print command, you don't really have to pass the _d_ flag 
> each time since you made it a global. You could just debug('foo'), and have 
> debug just look at the _d_ global. While you say you are nitpicky about 
> names, I get nitpicky about stuff like that, hah.
> 
> 
> 
> On Wed, Jul 11, 2012 at 2:11 PM, Jonas Avrin <tradigi...@gmail.com> wrote:
> Awesome, I had a feeling that was a possible slowdown, just hadn't gotten 
> around to testing it.   It was distracting how it seemed to get slower and 
> slower each time I ran it, got a little frustrating but I continued beefing 
> up error handling and practicing better var naming --btw i'm so nitpicky 
> about naming!!  Hypothetically, if I do have a heavy data container that is 
> more useful in a script, what do I use to decrease memory overhead?  del() 
> for example?  Thanks for responding, I will make those changes which should 
> work great and repost just in case someone wants it.  
> 
> On Wednesday, July 11, 2012 3:55:20 PM UTC-4, Justin Israel wrote:
> The reason its taking so long to update the graph editor is because every 
> single time your trigger the frameSelected(), it calls that extremely heavy 
> melGlobalsDict() operation. The funny thing is that ultimately you only need 
> one global variable in your highlightedRange()
> 
> I would make this following change: http://pastebin.com/USMPv0U2
> 
> Get rid of the whole massive env dump and just use this in your 
> highlightedRange():
>     time_ctrl = mm.eval('$tmp_ = $gPlayBackSlider')
> 
> I also had to make this change at the end of your fitGraph, because it wasn't 
> finding the view:
>     mc.animView(graphEd, startTime=zmin, endTime=zmax)
> 
> But now it runs fast with only a single global var lookup.
> 
> 
> 
> On Wed, Jul 11, 2012 at 11:24 AM, Jonas Avrin <tradigi...@gmail.com> wrote:
> 
> New version:
> http://pastebin.com/ASEqfXFM
> 
> Has renaming of vars implemented.
> 
> 
> On Wednesday, July 11, 2012 2:00:51 PM UTC-4, Jonas Avrin wrote:
> Ha, I know, I got creative today with the ascii ;)
> 
> Well, it's slow during the graph editor update process.  I will change the 
> vars to not use built in names.  It's just that they are simpler, but I know 
> I really shouldn't be using them.
> 
> On Wednesday, July 11, 2012 1:44:39 PM UTC-4, Justin Israel wrote:
> I think your ascii art is slowing the script down... j/k
> At first glance, this script doesn't appear to be doing much heavy work as it 
> is. What specific area is not performing well for you?
> 
> As a side note, sometimes its hard to follow the code when you regularly 
> shadow python built-ins as local variable names. Such as range, min, max... I 
> will be thinking "How is is using range like this...oh wait...its just a 
> list." Thats unrelated information though :-)
> 
> 
> On Wed, Jul 11, 2012 at 10:16 AM, Jonas Avrin <tradigi...@gmail.com> wrote:
> http://pastebin.com/mF77f95a
> 
> I have this script that acts like maya's autoFit function where it fits 
> curves automatically in the graph editor except this respects a frame range 
> argument and built in controls to turn on and off by the user.  Any ideas on 
> how to make this faster?
> 
> -- 
> view archives: http://groups.google.com/group/python_inside_maya
> change your subscription settings: 
> http://groups.google.com/group/python_inside_maya/subscribe
> 
> -- 
> view archives: http://groups.google.com/group/python_inside_maya
> change your subscription settings: 
> http://groups.google.com/group/python_inside_maya/subscribe
> 
> -- 
> view archives: http://groups.google.com/group/python_inside_maya
> change your subscription settings: 
> http://groups.google.com/group/python_inside_maya/subscribe
> 
> -- 
> view archives: http://groups.google.com/group/python_inside_maya
> change your subscription settings: 
> http://groups.google.com/group/python_inside_maya/subscribe

-- 
view archives: http://groups.google.com/group/python_inside_maya
change your subscription settings: 
http://groups.google.com/group/python_inside_maya/subscribe

Reply via email to