Best way to detect memory leaks
Hi all, What's the best way or tool to detect for potential memory leaks for Firedrake? Normally I use the PETSc log functions but in my Firedrake code I am doing lots of extra curricular programming which isn't seen by PETSc. Thanks, Justin
Hi Justin, On 30/11/16 20:11, Justin Chang wrote:
Hi all,
What's the best way or tool to detect for potential memory leaks for Firedrake? Normally I use the PETSc log functions but in my Firedrake code I am doing lots of extra curricular programming which isn't seen by PETSc.
"It's difficult" You can, in the normal way, use valgrind. But you have to build a custom Python install so that valgrind doesn't report lots of false positives. Normally, python objects will just be garbage-collected in the normal way. The worry is if you "accidentally" keep around references to them in various places. I think at the moment we're not doing so in firedrake itself, but maybe we've broken something again. Are you experiencing memory leaks, or is this more "idle" curiosity? Lawrence
Lawrence, So I was running large transient VI simulations and was noticing that each time level was getting slower and slower. I knew the equations were getting harder to solve but wasn't sure if it was also because of a memory leak. Turns out it was mostly the former, although at the time it was actually a combination of both because I noticed that the memory consumption per Ubuntu activity monitor was increasing. I wasn't efficiently implementing some python and UFL functions As of now I don't think I am experiencing anything, so this was more of a hypothetical situation in case it happens again. Justin On Thu, Dec 1, 2016 at 4:14 AM Lawrence Mitchell < lawrence.mitchell@imperial.ac.uk> wrote:
Hi Justin,
On 30/11/16 20:11, Justin Chang wrote:
Hi all,
What's the best way or tool to detect for potential memory leaks for Firedrake? Normally I use the PETSc log functions but in my Firedrake code I am doing lots of extra curricular programming which isn't seen by PETSc.
"It's difficult"
You can, in the normal way, use valgrind. But you have to build a custom Python install so that valgrind doesn't report lots of false positives.
Normally, python objects will just be garbage-collected in the normal way. The worry is if you "accidentally" keep around references to them in various places. I think at the moment we're not doing so in firedrake itself, but maybe we've broken something again.
Are you experiencing memory leaks, or is this more "idle" curiosity?
Lawrence
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
On 01/12/16 17:12, Justin Chang wrote:
Lawrence,
So I was running large transient VI simulations and was noticing that each time level was getting slower and slower. I knew the equations were getting harder to solve but wasn't sure if it was also because of a memory leak. Turns out it was mostly the former, although at the time it was actually a combination of both because I noticed that the memory consumption per Ubuntu activity monitor was increasing. I wasn't efficiently implementing some python and UFL functions
As of now I don't think I am experiencing anything, so this was more of a hypothetical situation in case it happens again.
So we have definitely in the past observed some issues with memory leaks in transient simulations. But I think I managed to squash them all. However, if you have something that exhibits memory growth, then it would be interesting to see, because it may be that we still have a bug in this area. Lawrence
participants (2)
-
Justin Chang
-
Lawrence Mitchell