On Tue, May 17, 2016 at 7:58 PM, Stefan Beller <sbel...@google.com> wrote: > On Mon, May 16, 2016 at 8:41 PM, Eric Sunshine <sunsh...@sunshineco.com> > wrote: >> On Mon, May 16, 2016 at 11:22 PM, Stefan Beller <sbel...@google.com> wrote: >>> When using automated tools to find memory leaks, it is hard to distinguish >>> between actual leaks and intentional non-cleanups at the end of the program, >>> such that the actual leaks hide in the noise. >>> >>> The end goal of this (unfinished) series is to close all intentional memory >>> leaks when enabling the -DFREE_ALL_MEMORY switch. This is just >>> demonstrating how the beginning of such a series could look like. >> >> Considering the signal-to-noise ratio mentioned above, the goal seems >> reasonable, but why pollute the code with #ifdef's all over the place >> by making the cleanup conditional? If you're going though the effort >> of plugging all these leaks, it probably makes sense to do them >> unconditionally. > > I tried that once upon a time. The resentment from the list was: > > We're exiting soon anyway (e.g. some cmd_foo function). Letting the > operating system clean up after us is faster than when we do it, so don't > do it.
Not a direct comment on this patch, but has anyone done some detailed performance testing of this with git? E.g. using a free() that just no-ops, or one that no-ops unless runtime > x_seconds, or no-ops unless total_allocated > some_limit. It might be interesting to play with that as a performance optimization. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
