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

Reply via email to