On Tue, Jan 05, 2021 at 10:45:35AM +0100, SZEDER Gábor wrote: > > But since c49c82aa4c (commit: move members graph_pos, generation to a > > slab, 2020-06-17), this optimization is broken, since asking for a > > 'commit_graph_generation()' directly returns GENERATION_NUMBER_INFINITY > > while writing. > > I wouldn't say that c49c82aa4c broke this optimisation, because: > > did not break that optimization. Though, sadly, it's not > mentioned in 3d11275505's commit message, when commit_gen_cmp() > compares two commits with identical generation numbers, then it > doesn't leave them unsorted, but falls back to use their committer > date as a tie-braker. This means that after c49c82aa4c the commits > are sorted by committer date, which appears to be so good a heuristic > for Bloom filter computation that there is barely any slowdown > compared to sorting by generation numbers: Gaah, scratch this paragraph; I first misunderstood what you wrote in the paragraph below, but then forgot to remove it. > > Not all hope is lost, though: 'commit_graph_generation()' falls back to > > You mean commit_gen_cmp() here. > > > comparing commits by their date when they have equal generation number, > > and so since c49c82aa4c is purely a date comparision function. This > > heuristic is good enough that we don't seem to loose appreciable > > performance while computing Bloom filters.
