From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9500C433F5 for ; Tue, 14 Sep 2021 05:23:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FAC760F92 for ; Tue, 14 Sep 2021 05:23:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239472AbhINFYj (ORCPT ); Tue, 14 Sep 2021 01:24:39 -0400 Received: from cloud.peff.net ([104.130.231.41]:46774 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239411AbhINFYi (ORCPT ); Tue, 14 Sep 2021 01:24:38 -0400 Received: (qmail 22791 invoked by uid 109); 14 Sep 2021 05:23:18 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 14 Sep 2021 05:23:18 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 19078 invoked by uid 111); 14 Sep 2021 05:23:16 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Tue, 14 Sep 2021 01:23:16 -0400 Authentication-Results: peff.net; auth=none Date: Tue, 14 Sep 2021 01:23:16 -0400 From: Jeff King To: Junio C Hamano Cc: Taylor Blau , git@vger.kernel.org Subject: Re: [PATCH 4/4] t5326: test propagating hashcache values Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Sep 13, 2021 at 07:05:32PM -0700, Junio C Hamano wrote: > Taylor Blau writes: > > > Alas, there they are. They are basically no different than having the > > name-hash for single pack bitmaps, it's just now we don't throw them > > away when generating a MIDX bitmap from a state where the repository > > already has a single-pack bitmap. > > I actually wasn't expecting any CPU/time difference. I was, for the same reason we saw an improvement there in ae4f07fbcc (pack-bitmap: implement optional name_hash cache, 2013-12-21): without a name-hash, we try a bunch of fruitless deltas before we find a decent one. > I hope that we are talking about the same name-hash, which is used > to sort the blobs so that when pack-objects try to find a good delta > base, the blobs from the same path will sit close to each other and > hopefully fit in the pack window. Yes, exactly. We spend less time finding the good ones if the likely candidates are close together. We may _also_ find better ones overall, depending on the number of candidates and the window size. The bitmap perf tests (neither p5310 nor its new midx cousin p5326) don't check the output size. > The effect I was hoping to see by not discarding the information was > that we find better delta base hence smaller deltas in the resulting > packfiles. If we add a size check like so[1]: diff --git a/t/perf/lib-bitmap.sh b/t/perf/lib-bitmap.sh index 63d3bc7cec..648cd5b13d 100644 --- a/t/perf/lib-bitmap.sh +++ b/t/perf/lib-bitmap.sh @@ -10,7 +10,11 @@ test_full_bitmap () { { echo HEAD && echo ^$have - } | git pack-objects --revs --stdout >/dev/null + } | git pack-objects --revs --stdout >tmp.pack + ' + + test_size 'fetch size' ' + wc -c