There was a bug in 6.2v3 that had to do with dependencies, so deleting
dependencies upstream of a node in a large tree went into a loop that was
pretty time consuming to delete. I wonder if this came back in some form? I
used this code to test:
def deleteUpstreamNodes(node):
"""deleteUpstreamNodes(node) -> deletes all nodes upstream of 'node'"""
allDeps = set()
depsList = [node]
while depsList:
deps = nuke.dependencies(depsList, nuke.INPUTS | nuke.HIDDEN_INPUTS)
depsList = [i for i in deps if i not in allDeps and not allDeps.add(i)]
for i in allDeps:
nuke.delete(i)
By doing an "import callbacksTrace" you can see all the nodes being destroyed
(well, any callback) as nuke closes. Basically, when you close the file, nuke
does an onDestroy callback to every node. I'd be curious if the above code
deletes a script's nodes as quickly (or as long) as it takes to normally close
it. If you have a script that is taking forever to close repeatably, maybe
adding the trace and monitoring where it gags can help spot the hangup.
JRAB
On Sep 12, 2013, at 9:37 PM, Julik Tarkhanov <ju...@hecticelectric.nl> wrote:
> Do you use fast storage for your disk cache and is aggressive caching
> enabled? I've seen this happen with shit storage when Nuke has to walk lots
> znd lots of cache files to delete them... On OSX tho.
>
> On 12 sep. 2013, at 17:38, "Richard Bobo" <richb...@mac.com> wrote:
>
>> with Nuke taking many minutes to unload a script from memory when it's
>> quitting
> _______________________________________________
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
