I believe the memory leak issue in single threaded node has been worked on. Should check the next beta release.
Chris On 2 Oct, 2013, at 5:12 AM, Mathias N <mdawn...@gmail.com> wrote: > If you happen to be running x64, would you (or anyone else listening in) > mind running the node and scene file below and seeing if it affects your > memory usage? > > http://www.mayulive.com/memleak.scn > http://www.mayulive.com/MemLeakSingleThread.dll > > (Post with files attached got stuck in the moderator queue due to file size > limits. Link to cancel it is not reachable so a duplicate may show up later) > > > On Tue, Oct 1, 2013 at 9:50 PM, Guillaume Laforge > <guillaume.laforge...@gmail.com> wrote: > This is strange because I'm actually working on a single threaded ICENode and > don't have any memory leaks. The output port is a single structure of type > Vec3 in 0D context. > I can run it on a mesh with 3 millions points for 10 000 frames without > memory issue. > > I'm using 2013 QFE7 btw. > > > > > On Tue, Oct 1, 2013 at 2:57 PM, Mathias N <mdawn...@gmail.com> wrote: > Thanks for the reply. > > The trial version I'm using is 2014 SP2. > Testing is being done in an empty scene with nothing but the newly created > pointcloud and a simple ice tree. There are no attribute display properties > present. > > To rule out any other possible culprits I created two identical nodes that > simply output the float input (0D component), one single-threaded and the > other multi-threaded. Both created via the wizard with the only manual change > being setting each to pass the value instead of printing it as the sample > code does. > > Switching between the two, the multi-threaded node barely affected memory > usage, while the single-threaded node resulted in a steady increase in memory > usage that was never released. > > It does not appear to have been fixed in SP2 :( > > Given that I am only passing a relatively modest number of components through > it, I can imagine this would be quite a showstopper for larger sets of data. > > > > On Tue, Oct 1, 2013 at 7:25 PM, Guillaume Laforge > <guillaume.laforge...@gmail.com> wrote: > Hi, > > Indeed, there has been some memory leaks issues in the past. If you were > testing in 2014, you should try 2014 SP2 as it fixed (some parts) of the ICE > related memory issue. > If 2014 SP2 doesn't fix the pb you can also check if you've got some > attribute display properties on your objects. They could be the culprit. > > Guillaume > > > On Tue, Oct 1, 2013 at 12:24 PM, Mathias N <mdawn...@gmail.com> wrote: > Please excuse any errors; mailing lists are confusing. > > While wrapping up work on a system that includes 5 custom icenodes, I noticed > that memory usage was increasing by about 1mb per second during playback. > > I eventually narrowed it down to a per-point-array node, the only > single-threaded node in the setup. In a test scene I have it reading about 30 > turbulized mesh point positions and spitting them into a single per-object > array, and after leaving it for 15-30 minutes a while memory usage had > increased from 400mb to 1.5gb. It is not released until the program is closed. > > Being at loss as to what might be causing it I removed everything but the > absolute necessary pieces of the code (port declarations etc), only to find > that the problem persisted. > > Next I created a new icenode using the wizard, adding one input and one > output port with the default settings, and setting it to single threaded. > This also slowly increases memory consumption when executed. Using an 8x8x8 > grid as input it increases memory usage by about 150kb per second. > > If the input is singular (object context) there is no perceivable increase in > memory usage. The rate of increase appears to be relative to the number of > input components. > > I primarily use Softimage 2011, but running it in the 2014 trial produces the > same result. Were it a legitimate bug it would seem unlikely that it would > persist for so long. > > Could anyone shed some light on what is going on here? Is this normal? > > Thanks > > > -------------------------- > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject > "unsubscribe" and reply to the confirmation email. > > > -------------------------- > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject > "unsubscribe" and reply to the confirmation email. > > > -------------------------- > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject > "unsubscribe" and reply to the confirmation email. > > > -------------------------- > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject > "unsubscribe" and reply to the confirmation email. > > -------------------------- > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject > "unsubscribe" and reply to the confirmation email.
-------------------------- To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject "unsubscribe" and reply to the confirmation email.
