diff options
author | Elijah Newren <newren@gmail.com> | 2020-11-02 18:55:04 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-11-02 12:15:50 -0800 |
commit | 33f20d82177871225e17d9dd44169a52a36c9f1d (patch) | |
tree | 049a082449a6253743b11ca5c88cf88b4bb90b2a /t/t5411/test-0023-report-unexpect-ref--porcelain.sh | |
parent | hashmap: allow re-use after hashmap_free() (diff) | |
download | tgif-33f20d82177871225e17d9dd44169a52a36c9f1d.tar.xz |
hashmap: introduce a new hashmap_partial_clear()
merge-ort is a heavy user of strmaps, which are built on hashmap.[ch].
clear_or_reinit_internal_opts() in merge-ort was taking about 12% of
overall runtime in my testcase involving rebasing 35 patches of
linux.git across a big rename. clear_or_reinit_internal_opts() was
calling hashmap_free() followed by hashmap_init(), meaning that not only
was it freeing all the memory associated with each of the strmaps just
to immediately allocate a new array again, it was allocating a new array
that was likely smaller than needed (thus resulting in later need to
rehash things). The ending size of the map table on the previous commit
was likely almost perfectly sized for the next commit we wanted to pick,
and not dropping and reallocating the table immediately is a win.
Add some new API to hashmap to clear a hashmap of entries without
freeing map->table (and instead only zeroing it out like alloc_table()
would do, along with zeroing the count of items in the table and the
shrink_at field).
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5411/test-0023-report-unexpect-ref--porcelain.sh')
0 files changed, 0 insertions, 0 deletions