Yep, nice summary. Probably I should have also mentioned:
- An extra stack frame with no locals is not a lot of overhead, but
in any case these are by design not in performance-critical places.
- By using a special function like this, we make instances nicely
grep-able and give the leak prominence in t/valgrind/default.supp.
So a person can discover, for example, that writing a lot of trees
in a single process (like cherry-pick -n foo..bar currently does)
is going to be leaky.
- valgrind would be most useful if it can be used to identify
_regressions_ by running the test suite with --valgrind. git is
deliberately leaky in a lot of places; it is not useful to record
that.
- valgrind does have the ability to turn suppressions off if you want.
Jonathan Nieder <jrnieder@gmail.com>