Am 26.02.24 um 03:05 schrieb Junio C Hamano: > René Scharfe <l.s.r@xxxxxx> writes: > >> 1c56fc2084 (name-rev: pre-size buffer in get_parent_name(), 2020-02-04) >> got a big performance boost in an unusual repository by calculating the >> name length in advance. This is a bit awkward, as it references the >> name components twice. >> >> Use a memory pool to store the strings for the struct rev_name member >> tip_name. Using mem_pool_strfmt() allows efficient allocation without >> explicit size calculation. This simplifies the formatting part of the >> code without giving up performance: >> >> Benchmark 1: ./git_2.44.0 -C ../chromium/src name-rev --all >> Time (mean ± σ): 1.231 s ± 0.013 s [User: 1.082 s, System: 0.136 s] >> Range (min … max): 1.214 s … 1.252 s 10 runs >> >> Benchmark 2: ./git -C ../chromium/src name-rev --all >> Time (mean ± σ): 1.220 s ± 0.020 s [User: 1.083 s, System: 0.130 s] >> Range (min … max): 1.197 s … 1.254 s 10 runs >> >> Don't bother discarding the memory pool just before exiting. The effort >> for that would be very low, but actually measurable in the above >> example, with no benefit to users. At least UNLEAK it to calm down leak >> checkers. This addresses the leaks that 45a14f578e (Revert "name-rev: >> release unused name strings", 2022-04-22) brought back. >> >> Signed-off-by: René Scharfe <l.s.r@xxxxxx> >> --- >> This doesn't make any test script leak-free, though. > > Hmph, is the root cause of the leak because no sensible ownership > rules are applied to .tip_name? Sometimes it is allocated for the > paritcular rev_name, but some other times the pointer is copied from > another rev_name.tip_name? As the way currently the code uses the > .tip_name member seems to be "allocate and use without any freeing", > I tend to agree that throwing them into mem-pool does make sense. Yes, the tip_name string is shared between child and first parent (and its first parent and so on, until a better name is found. Without this sharing the peak memory footprint of "git name-rev --all" in Git's repo goes from 40011328 to 46286528 for me currently. I'm not too worried about the leak, though, as we can't release the memory until we're done anyway. The ability to build strings without having to calculate their sizes in advance (either by running vsnprintf twice, which is slow, or by doing format-specific calculations) is more interesting to me. The reason why none of the test scripts become leak-free is other commands (i.e. not git name-rev) that are still leaking. René
