Peter,

Thank you for your detailed response! This sounds like exactly what we have 
been experiencing. At the moment, we have been stuck on Nuke 7.0v4. I will look 
forward to trying out the improvements to memory handling - just as soon as our 
busy schedule permits, that is!  ;^)

Rich


On Sep 13, 2013, at 5:46 AM, Peter Crossley <[email protected]> wrote:

> Hi,
> 
> There were two bugs which were windows specific - 
> 
> Bug 35284 - Windows - exit unacceptably slow as mem released in tiny 
> increments; substantial farm impact
> Bug 30903 - Drastic difference in render times using the script in different 
> OS
> 
> Both of these highlighted that for specific scripts Nuke was vastly slower on 
> Windows compared to the other two platforms.
> 
> We narrowed this down to the performance of the windows system allocator for 
> multi-threaded allocations and deallocations. We replaced the windows system 
> allocator with tcmalloc for all allocations done through DDImage. For these 
> cases. this solved the problem and resulted in performance similar to Osx and 
> Linux. (Note that for the other platforms, the system allocators already work 
> in a similar way to tcmalloc, so there is little to be gained by switching 
> these allocators too). This behaviour can be switched on by an environment 
> variable for Nuke 7.0v8, and will be enabled by default in the next major 
> release.
> 
> If any users are still experiencing similar problems, including things that 
> are non platform specific, then please contact support. Any scripts, footage, 
> assets you could provide that exhibit the problem would be massively useful, 
> and will help us to identify and fix the problem.
> 
> Hope that helps!
> 
> Cheers,
> 
> Peter.
> 
> 
> On 12/09/2013 20:02, Richard Bobo wrote:
>> Hmm… sounds like a very common problem on more than just the Windows 
>> platform. Has anyone filed a bug report for this?  It seems like having to 
>> use the "kill the app" method to substitute for a normal program exit would 
>> qualify as a "bug"…
>> 
>> Rich
>> 
>> 
>> On Sep 12, 2013, at 12:10 PM, Diogo Girondi <[email protected]> wrote:
>> 
>>> I've faced this problem several times in OSX with projects loaded with R3D 
>>> files at full res and camera projections with large JPG files. So I don't 
>>> think it's exclusive to Windows.
>>> 
>>> In OSX when this happens, clearing the buffers and the disk cache will also 
>>> take forever, so I usually end up force quitting Nuke most of the times. 
>>> It's just quicker.
>>> 
>>> Ok that the scene memory usage wasn't on the low side, but...
>>> 
>>> 
>>> 
>>> iMac i7 32GB of RAM OSX 10.8.4
>>> 
>>> cheers,
>>> diogo
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Sep 12, 2013 at 12:58 PM, Nathan Rusch <[email protected]> 
>>> wrote:
>>> I’ve gotten many complaints about this from artists as well, all running on 
>>> Linux. So far the best solutions are either A) kill Nuke, or B) manually 
>>> clear buffers before closing. The latter doesn’t really avoid the problem 
>>> though; just makes it less apparent.
>>>  
>>> I would love some insight into the root of this issue.
>>>  
>>> -Nathan
>>> 
>>>  
>>> From: Peter Crossley
>>> Sent: Thursday, September 12, 2013 8:53 AM
>>> To: [email protected]
>>> Subject: Re: [Nuke-users] Nuke takes *forever* to unload memory (Windows 7)
>>>  
>>> Ah, Windows 7, just noticed ;)
>>> 
>>> On 12/09/2013 16:53, Peter Crossley wrote:
>>>> Hi Rich, 
>>>> 
>>>> Is this in a Windows build? If so, and you're using Nuke 7.0v8 you can try 
>>>> setting the environment variable NUKE_USE_FAST_ALLOCATOR to 1. This might 
>>>> solve your problem. (Note, this is windows only!)
>>>> 
>>>> Cheers,
>>>> 
>>>> Peter.
>>>> 
>>>> On 12/09/2013 16:36, Richard Bobo wrote:
>>>>> Hi all,
>>>>>  
>>>>> Just wondering if other folks have an issue with Nuke taking many minutes 
>>>>> to unload a script from memory when it's quitting? I often end up killing 
>>>>> Nuke, instead of letting it finish closing on its own, since it can take 
>>>>> many minutes to slowly purge itself from memory! If this is a common 
>>>>> problem, it seems like a bug report might be apropos…  Anyone else?
>>>>>  
>>>>> Rich
>>>>>  
>>>>> 
>>>>> Rich Bobo
>>>>> Senior VFX Compositor
>>>>> Armstrong-White
>>>>> http://armstrong-white.com/
>>>>>  
>>>>> Email:  [email protected]
>>>>> Mobile:  (248) 840-2665
>>>>> Web:  http://richbobo.com/
>>>>> 
>>>>> "Destiny is not a matter of chance, it is a matter of choice; it is not a 
>>>>> thing to be waited for, it is a thing to be achieved."
>>>>> - William Jennings Bryan
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Nuke-users mailing list
>>>>> [email protected], http://forums.thefoundry.co.uk/
>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Nuke-users mailing list
>>> [email protected], http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>> 
>>> 
>>> _______________________________________________
>>> Nuke-users mailing list
>>> [email protected], http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>> 
>>> _______________________________________________
>>> Nuke-users mailing list
>>> [email protected], http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>> 
>> 
>> 
>> _______________________________________________
>> Nuke-users mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> 
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to