Skip to content

Commit 359b01c

Browse files
peffgitster
authored andcommitted
ref-filter: disable save_commit_buffer while traversing
Various ref-filter options like "--contains" or "--merged" may cause us to traverse large segments of the history graph. It's counter-productive to have save_commit_buffer turned on, as that will instruct the commit code to cache in-memory the object contents for each commit we traverse. This increases the amount of heap memory used while providing little or no benefit, since we're not actually planning to display those commits (which is the usual reason that tools like git-log want to keep them around). We can easily disable this feature while ref-filter is running. This lowers peak heap (as measured by massif) for running: git tag --contains 1da177e in linux.git from ~100MB to ~20MB. It also seems to improve runtime by 4-5% (600ms vs 630ms). A few points to note: - it should be safe to temporarily disable save_commit_buffer like this. The saved buffers are accessed through get_commit_buffer(), which treats the saved ones like a cache, and loads on-demand from the object database on a cache miss. So any code that was using this would not be wrong, it might just incur an extra object lookup for some objects. But... - I don't think any ref-filter related code is using the cache. While it's true that an option like "--format=%(*contents:subject)" or "--sort=*authordate" will need to look at the commit contents, ref-filter doesn't use get_commit_buffer() to do so! It always reads the objects directly via read_object_file(), though it does avoid re-reading objects if the format can be satisfied without them. Timing "git tag --format=%(*authordate)" shows that we're the same before and after, as expected. - Note that all of this assumes you don't have a commit-graph file. if you do, then the heap usage is even lower, and the runtime is 10x faster. So in that sense this is not urgent, as there's a much better solution. But since it's such an obvious and easy win for fallback cases (including commits which aren't yet in the graph file), there's no reason not to. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent e4a4b31 commit 359b01c

File tree

1 file changed

+5
-0
lines changed

1 file changed

+5
-0
lines changed

ref-filter.c

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2405,13 +2405,17 @@ static void reach_filter(struct ref_array *array,
24052405
int filter_refs(struct ref_array *array, struct ref_filter *filter, unsigned int type)
24062406
{
24072407
struct ref_filter_cbdata ref_cbdata;
2408+
int save_commit_buffer_orig;
24082409
int ret = 0;
24092410

24102411
ref_cbdata.array = array;
24112412
ref_cbdata.filter = filter;
24122413

24132414
filter->kind = type & FILTER_REFS_KIND_MASK;
24142415

2416+
save_commit_buffer_orig = save_commit_buffer;
2417+
save_commit_buffer = 0;
2418+
24152419
init_contains_cache(&ref_cbdata.contains_cache);
24162420
init_contains_cache(&ref_cbdata.no_contains_cache);
24172421

@@ -2444,6 +2448,7 @@ int filter_refs(struct ref_array *array, struct ref_filter *filter, unsigned int
24442448
reach_filter(array, filter->reachable_from, INCLUDE_REACHED);
24452449
reach_filter(array, filter->unreachable_from, EXCLUDE_REACHED);
24462450

2451+
save_commit_buffer = save_commit_buffer_orig;
24472452
return ret;
24482453
}
24492454

0 commit comments

Comments
 (0)