Nevermind. I read it wrong. Its still a local var. Carry on. But there is the loose dprint call on 124
On Jul 11, 2012, at 3:43 PM, Justin Israel <[email protected]> wrote: > 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 <[email protected]> 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 <[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 >> >> 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 >> 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
