each 3delight IPR restart slows down render

[michalfratczak]

Version: Gaffer 1.4.11.0-windows
Third-party tools: 3delight-2.9.108 windows
Third-party modules: None

Description

Each restart of 3delight IPR slows down rendering and CPU usage. After many restarts, the renders are really slow.
Restarting whole gaffer resets the situation to normal (until next restarts).
I tried with both ieDisplay and i-display, no difference here.

Here is video showing a few IPR restarts and full gaffer restart. Take a look at the end, where it gets really slow.
https://youtu.be/KMrGuL3Wyqo

Here is gaffer script with Digital Emily asset (with textures) - 2 GB !!
http://cgarea.com/emily_gaffer.zip

Steps to reproduce

1. stop and restart IPR render many times

[johnhaddon]

Since this is on Windows, my first guess would be that the problem is related to the default memory allocator in Windows, which is known to have very poor performance. In this thread Eric provided a patched binary with a custom memory allocator that you could copy into your Gaffer installation. If you could give that a try and let us know if it helps, that would be very valuable. Obviously not a long-term solution, but if we can gather evidence that this helps in multiple situations, it gives us more motivation to find a way of getting it into a standard release.

The other test that might be useful would be to repeat the same on Linux, to check that there's not a similar problem there.

[michalfratczak]

The patched python binary seems to fix the problem - renders are fast and responsive again.
I am unable to test under linux for this moment.

[johnhaddon]

That's good news - thanks for testing. We'll have to see what we can do about making the custom memory allocator a standard thing.

[aghiles]

IMHO, my feeling is that you have a memory leak somewhere in your code and one allocator is just better at handling this case than the other.

[johnhaddon]

Closing, since the custom allocator is now standard in Gaffer 1.5.0.0a3 and above. @aghiles, we haven't seen any evidence for this being related to a memory leak, but we're happy to take another look if you are able to back up your humble opinion with evidence :)