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 <[email protected]> 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<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 <[email protected]>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 >>>>>> <[email protected]>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<http://groups.google.com/group/python_inside_maya> >>>>>>> change your subscription settings: http://groups.google.com/**group* >>>>>>> */python_inside_maya/**subscribe<http://groups.google.com/group/python_inside_maya/subscribe> >>>>>>> >>>>>> >>>>>> -- >>>> view archives: >>>> http://groups.google.com/**group/python_inside_maya<http://groups.google.com/group/python_inside_maya> >>>> change your subscription settings: http://groups.google.com/** >>>> group/python_inside_maya/**subscribe<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
