You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
unpack-trees: improve performance of next_cache_entry
To find the first non-unpacked cache entry, `next_cache_entry` iterates through
index, starting at `cache_bottom`, to find the first cache entry. The
performance of this in full indexes is helped by `cache_bottom` advancing with
each invocation of `mark_ce_used` (called by `unpack_index_entry`). However,
the presence of sparse directories can prevent the `cache_bottom` from
advancing in a sparse index case, effectively forcing `next_cache_entry` to
search from the beginning of the index each time it is called.
The need to preserve `cache_bottom` for the sparse index is documented in
17a1bb5, so to get the benefit it provides in "shortcutting"
already-searched entries a separate `hint` position is used. The hint position
is set inside of `next_cache_entry` to `last_searched_position + 1`, allowing
full _and_ sparse index iterations to skip already-searched entries. The
performance is significantly improved for the sparse index case based on the
`p2000` results for a `git reset` with a non-matching pathspec (heavily using
`next_cache_entry`):
Test ms/vfs-2.33.0 HEAD
------------------------------------------------------
(full-v3) 0.79(0.38+0.30) 0.91(0.43+0.34) +15.2%
(full-v4) 0.80(0.38+0.29) 0.85(0.40+0.35) +6.2%
(sparse-v3) 0.76(0.43+0.69) 0.44(0.08+0.67) -42.1%
(sparse-v4) 0.71(0.40+0.65) 0.41(0.09+0.65) -42.3%
Signed-off-by: Victoria Dye <[email protected]>
0 commit comments