Re: [RFD PATCH 0/3] Free all the memory!
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- May 18, 2016, 15:19 UTC
- Message-ID
- <CACBZZX6t5RsTe0GCPifA9cq7wbChY-ekVXZOYSqPTuOHp_D4Vw@mail.gmail.com>
- In-Reply-To
- <CAGZ79kaJoAxqtsTuErQSgJiVeD_vdZ1MQXKr-LTtyro-FbscTQ@mail.gmail.com>
On Tue, May 17, 2016 at 7:58 PM, Stefan Beller <sbeller@google.com> wrote:
Show 21 quoted lines
> On Mon, May 16, 2016 at 8:41 PM, Eric Sunshine <sunshine@sunshineco.com> wrote: >> On Mon, May 16, 2016 at 11:22 PM, Stefan Beller <sbeller@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.