From patchwork Fri Dec 20 17:19:47 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Tan X-Patchwork-Id: 13917162 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB44322653E for ; Fri, 20 Dec 2024 17:19:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734715201; cv=none; b=psqOwEkfvgz0yk+EGvjCEoDmrr0QjElPI4h1VGV2qWQ3ittAa6zwfDCkjLA1f91JCezTFAR6FjgE2z8E9kCQpB92OusPc/3NRcS34fL3hLpmo70VpiqFrKDOWARsaRdgO5SK5/sO1+xuIzPG6ib+vB6fqPpJtL1ObsSmBJ8iAJs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734715201; c=relaxed/simple; bh=k8MQC+N2aVbjxI5hoHkypI0UkbjCFdXsq4kXmVJXDr0=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=fCdmvPcWF+j3Wc5zZNZ8aoZsOLpdOKSkx3G+nMVBSZBSxJpFYDcH4A9ZGkn2okZoQkgRjf6AwyxThI51R7nLNpqkZy7iqyonXva/OxnPltByzujXCcIWzLyQ8oOtuuYMAHiJ8LsrgVGjthLqLRyKfUtagPHnWxH+I+XSkcQlxtc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=I9PffYdQ; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="I9PffYdQ" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-436202dd7f6so23468275e9.0 for ; Fri, 20 Dec 2024 09:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734715198; x=1735319998; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=JZMEj2Cgkx4xj43UqaYcdHWu3cPiAf8tko9NUF8PKIQ=; b=I9PffYdQp4qA97+bybeQ2NblRTNOWCIdfZq6hzh2TRFESUuh0m9NpKv8mA5yHKQggU El/G18iWO7cAMzWln+afjFPQ6mhRlyOCUpgpXDuoONdfngv13uvSCI5rEUShd11vjATB xK++i4NPlIXgAp2Mlj4MKTencEpq3jxBxYrzztq+BgOI0g11tsh6us7ZoI+zKqbBmcD7 16zrXX9RDOoKyltlA6JAJEGjYcfUJlyNANFDAS3QkDGLLRsEeaIuW3CUWoDMAIuVNeF8 rQqeloHBQY+MgybBSa6ouxp25/8MfFvPW/xWuxPG0WGWcglicZOwcjbVXG6YfgWNzAEf j5cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734715198; x=1735319998; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JZMEj2Cgkx4xj43UqaYcdHWu3cPiAf8tko9NUF8PKIQ=; b=JjVuDeGOH7euPu4Pk/ekajTOMfRO+AW7s18pMVRWw8iQwD1Ag5ZzcyvFKfaLaigGjM NGlpPEgtiT4rlHcuYvQIyHZL04P9X7jPDUF08M0QKyecifmLGxCQ5lI4Yk5+EuLGOGU8 kx3FuFDtSj0+qz9wxITQjZ9bi8Llpdivea6xQ/WBVFOAX6t+hdbwdcaG3OVDhhAdrt+U O8zsOnys+OcCNwDttjopP4+hTAkYIkZxO4fzKFbvBsX2JQzH5GJy3QKJTQVDXAHm5u09 4+h3x/gbABYBlUhSB/yhRf2Uiaki507UNkV7K51GTwHIcU8MTuToIsyItyvXvJ1N3AUQ 7BbQ== X-Gm-Message-State: AOJu0YzrImWhEsLwsgocH8h1FDDgDW7ODaMjY5pgBU6gsBeuXbgJn+82 XZb2oYKpiUP38NvyS8utUvrDtSYqJNjbQul9PQS9dJqel4gJQ1P9xJyhwA== X-Gm-Gg: ASbGncvx+gJ0rb1jDM9RqsYJDaLv4+7uJH3W3qUPAHfH3GEn9Araoi/5KE96/wkT6Ct TEM7u+S/WK1UZNq2Gebb6VvUZ5hX4OI1FO54osNcmapoTY8Z6lMZZNe7T9szAWuBMYbiJXOHqB+ 8MY1x4uGJR/ZXBLjc3RnXQudg0uQJ1s/iXVnJtMBOKShBgKie+0uGVNqcFIdJiiL68Anz3ZUqgn iajdpA9iTnmI/5yO+N55VcwyJd8zrKlIS8yZDFyIqSv6+Jv1/apYneqBg== X-Google-Smtp-Source: AGHT+IFByzXaLoQ1L1bqYf/vwszYgHuHgUG0kllXfiP2H1o1lwQ6VPoVfHBTLK86O0IqLkGeXCqkAg== X-Received: by 2002:a05:600c:4509:b0:436:1971:2a4 with SMTP id 5b1f17b1804b1-4366864722emr35326795e9.17.1734715197688; Fri, 20 Dec 2024 09:19:57 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436612008bcsm50650585e9.16.2024.12.20.09.19.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2024 09:19:57 -0800 (PST) Message-Id: <68b4127580e2d475bec0d7cd0f6a9ae5e626b3c9.1734715194.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Fri, 20 Dec 2024 17:19:47 +0000 Subject: [PATCH v3 1/8] pack-objects: create new name-hash function version Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: gitster@pobox.com, johannes.schindelin@gmx.de, peff@peff.net, ps@pks.im, me@ttaylorr.com, johncai86@gmail.com, newren@gmail.com, jonathantanmy@google.com, karthik nayak , Derrick Stolee , Jonathan Tan From: Jonathan Tan From: Jonathan Tan As we will explore in later changes, the default name-hash function used in 'git pack-objects' has a tendency to cause collisions and cause poor delta selection. This change creates an alternative that avoids some collisions while preserving some amount of hash locality. The pack_name_hash() method has not been materially changed since it was introduced in ce0bd64 (pack-objects: improve path grouping heuristics., 2006-06-05). The intention here is to group objects by path name, but also attempt to group similar file types together by making the most-significant digits of the hash be focused on the final characters. Here's the crux of the implementation: /* * This effectively just creates a sortable number from the * last sixteen non-whitespace characters. Last characters * count "most", so things that end in ".c" sort together. */ while ((c = *name++) != 0) { if (isspace(c)) continue; hash = (hash >> 2) + (c << 24); } As the comment mentions, this only cares about the last sixteen non-whitespace characters. This cause some filenames to collide more than others. This collision is somewhat by design in order to promote hash locality for files that have similar types (.c, .h, .json) or could be the same file across a directory rename (a/foo.txt to b/foo.txt). This leads to decent cross-path deltas in cases like shallow clones or packing a repository with very few historical versions of files that share common data with other similarly-named files. However, when the name-hash instead leads to a large number of name-hash collisions for otherwise unrelated files, this can lead to confusing the delta calculation to prefer cross-path deltas over previous versions of the same file. The new pack_name_hash_v2() function attempts to fix this issue by taking more of the directory path into account through its hash function. Its naming implies that we will later wire up details for choosing a name-hash function by version. The first change is to be more careful about paths using non-ASCII characters. With these characters in mind, reverse the bits in the byte as the least-significant bits have the highest entropy and we want to maximize their influence. This is done with some bit manipulation that swaps the two halves, then the quarters within those halves, and then the bits within those quarters. The second change is to perform hash composition operations at every level of the path. This is done by storing a 'base' hash value that contains the hash of the parent directory. When reaching a directory boundary, we XOR the current level's name-hash value with a downshift of the previous level's hash. This perturbation intends to create low-bit distinctions for paths with the same final 16 bytes but distinct parent directory structures. The collision rate and effectiveness of this hash function will be explored in later changes as the function is integrated with 'git pack-objects' and 'git repack'. Signed-off-by: Jonathan Tan Signed-off-by: Derrick Stolee --- pack-objects.h | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/pack-objects.h b/pack-objects.h index b9898a4e64b..681c1116486 100644 --- a/pack-objects.h +++ b/pack-objects.h @@ -207,6 +207,34 @@ static inline uint32_t pack_name_hash(const char *name) return hash; } +static inline uint32_t pack_name_hash_v2(const unsigned char *name) +{ + uint32_t hash = 0, base = 0, c; + + if (!name) + return 0; + + while ((c = *name++)) { + if (isspace(c)) + continue; + if (c == '/') { + base = (base >> 6) ^ hash; + hash = 0; + } else { + /* + * 'c' is only a single byte. Reverse it and move + * it to the top of the hash, moving the rest to + * less-significant bits. + */ + c = (c & 0xF0) >> 4 | (c & 0x0F) << 4; + c = (c & 0xCC) >> 2 | (c & 0x33) << 2; + c = (c & 0xAA) >> 1 | (c & 0x55) << 1; + hash = (hash >> 2) + (c << 24); + } + } + return (base >> 6) ^ hash; +} + static inline enum object_type oe_type(const struct object_entry *e) { return e->type_valid ? e->type_ : OBJ_BAD; From patchwork Fri Dec 20 17:19:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Derrick Stolee X-Patchwork-Id: 13917164 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C39C21C192 for ; Fri, 20 Dec 2024 17:20:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734715203; cv=none; b=PZSmXTFbCtLOTkKYW/zXMQACJNyKKT1lnuhHTeB2VRtY5FI/JyIzDeJKE3bY9Fzt4IZvUCY1yxXpYyV4+mFso25eHqQRfHJfCcqSVA2llxoJ7Jo6PFkj7MdAUZz2VvbDnKUTwItDhec1SfxzUIBGlagrsHcMtEo0WH5X//gI/CM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734715203; c=relaxed/simple; bh=yKiLqgSSThEMnZI3WBPPa4bUr1sjaHFxQLKdd2wyPf4=; h=Message-Id:In-Reply-To:References:From:Date:Subject:Content-Type: MIME-Version:To:Cc; b=qS4RlH6/v+tPzlmTBbh9kc+0HW/3KrENTYIoC7U0mVat1rONk2vtCUBrXMmIr/Fhy4a/wEipka/LQpgvKNVFHbhKan7ujG7sWRoUTFZLxEqgV9UfApGnBiq8ytsqymesFRNGSUg+Kqvnx8dVbG9sxtI67lSGBgJHe//ixhr5DhY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Oke+e3mg; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Oke+e3mg" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-3862d161947so1124019f8f.3 for ; Fri, 20 Dec 2024 09:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734715199; x=1735319999; darn=vger.kernel.org; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:from:to:cc:subject:date :message-id:reply-to; bh=zRyM+efCIVNr5zfeFLfApVvj4fwKDdYbdXJrWPLwvb0=; b=Oke+e3mgPi6DG2HPEEa95zM5F/CG3Q57L0w6SKx6LqcIvzZtCkciylwTRf1hbqUZw6 r9dTU9bkj0BvxjanDeLG2YWT0zeYVwUBZif7Z7ybCjn1caZ/vgGtbNQBRsbtZtAZMzUE zxDLkjt3VykbAGNn175d70pbvXCKceY9HHCsgs9pZC9Fow4Rg2t1EsDPx9nQzMynFt7f 1CSSgP4xngKgyZHXIiqaKFrqCJWdhFzFVoGmHvVK+2xDAE4D/UzTjI+vixm8mO75Cz0i BgS6zAMXsVswn7wSJzWyq8wtya3Fp3fDOZ2jW1FpFI86WDH/W0NJCxX6/k6FdYNiIyDU XW3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734715199; x=1735319999; h=cc:to:mime-version:content-transfer-encoding:fcc:subject:date:from :references:in-reply-to:message-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zRyM+efCIVNr5zfeFLfApVvj4fwKDdYbdXJrWPLwvb0=; b=GbVYdD3t08eHWTSd5M8W5GRpUQ2S3f39QBpXhKBtiESdEkxn8EyrXWtSqwHot3tpqC E6k/IFxjcnLjesfFi3JOUcgPp/Oc8gSTwihbBHwJXKl1XSbiD8zT3LSmxTBpd33X5cZG 67MDGdfrgFcs3+9uEOGaSTJCyoX7jFSQJPx9Ha9X9xU0lTig6lGBKQPAdkwnGmTdgpWu r4rPE4igw0i5dKlP9mI28vrPfBVaHZRBW8cIJ7vIwpjM/atRT8cI52wfetaA2pzVTrpv r7SFmnbvsIUtqoLxx4bTlEFLIxkSrbLmGz+Xk497XJ8uo8xE3Cx90KqQHLrHD7sA60kD 9xPA== X-Gm-Message-State: AOJu0YzCj75mDbRG4AuobslkQzwnV8o8dwCi7CYioXGOuIexfZy4gBY/ SSfTV2UCruAeLtyMNE0wkNJivs37XRwKItYjc4jcH2lHeRjRNWTognYr7Q== X-Gm-Gg: ASbGncvcHUZBhy7UPw5ldJOpiuku7+CRZeKHcIFJ5Zpr8CM9fbC7SGC+c1isF2zWaAC ZySd4Wf41WAa8X5gaUoyN/pXrx7t4p/6eWovfrz5+5JwodZlDxzq+87ArLeYS8GtDuvSjhjtYoH kr5AIsV3E57t3lIvH5V/vhQtO1MM6rrYjI/nlsL+AYjIAOVxx9/lC0BwXMs3EdvqgQWGlg7wyPs xjjS3oEy9YJj1TDUOYpM1s3ikDQvqHZgrMd+m/EnM3YhjRM2z/gG9hBhQ== X-Google-Smtp-Source: AGHT+IFBJsZEirmmLOcERemnAuWftZcwv0rlockMCnpe/AHQKAAtcj5DYJYhr6TVkN0rZaT8OYEdZQ== X-Received: by 2002:a05:6000:178c:b0:386:4a24:1914 with SMTP id ffacd0b85a97d-38a223f7219mr3284127f8f.37.1734715198950; Fri, 20 Dec 2024 09:19:58 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43661219611sm51524335e9.23.2024.12.20.09.19.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2024 09:19:58 -0800 (PST) Message-Id: In-Reply-To: References: Date: Fri, 20 Dec 2024 17:19:48 +0000 Subject: [PATCH v3 2/8] pack-objects: add --name-hash-version option Fcc: Sent Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: git@vger.kernel.org Cc: gitster@pobox.com, johannes.schindelin@gmx.de, peff@peff.net, ps@pks.im, me@ttaylorr.com, johncai86@gmail.com, newren@gmail.com, jonathantanmy@google.com, karthik nayak , Derrick Stolee , Derrick Stolee From: Derrick Stolee From: Derrick Stolee The previous change introduced a new pack_name_hash_v2() function that intends to satisfy much of the hash locality features of the existing pack_name_hash() function while also distinguishing paths with similar final components of their paths. This change adds a new --name-hash-version option for 'git pack-objects' to allow users to select their preferred function version. This use of an integer version allows for future expansion and a direct way to later store a name hash version in the .bitmap format. For now, let's consider how effective this mechanism is when repacking a repository with different name hash versions. Specifically, we will execute 'git pack-objects' the same way a 'git repack -adf' process would, except we include --name-hash-version= for testing. On the Git repository, we do not expect much difference. All path names are short. This is backed by our results: | Stage | Pack Size | Repack Time | |-----------------------|-----------|-------------| | After clone | 260 MB | N/A | | --name-hash-version=1 | 127 MB | 129s | | --name-hash-version=2 | 127 MB | 112s | This example demonstrates how there is some natural overhead coming from the cloned copy because the server is hosting many forks and has not optimized for exactly this set of reachable objects. But the full repack has similar characteristics for both versions. Let's consider some repositories that are hitting too many collisions with version 1. First, let's explore the kinds of paths that are commonly causing these collisions: * "/CHANGELOG.json" is 15 characters, and is created by the beachball [1] tool. Only the final character of the parent directory can differentiate different versions of this file, but also only the two most-significant digits. If that character is a letter, then this is always a collision. Similar issues occur with the similar "/CHANGELOG.md" path, though there is more opportunity for differences In the parent directory. * Localization files frequently have common filenames but differentiates via parent directories. In C#, the name "/strings.resx.lcl" is used for these localization files and they will all collide in name-hash. [1] https://github.com/microsoft/beachball I've come across many other examples where some internal tool uses a common name across multiple directories and is causing Git to repack poorly due to name-hash collisions. One open-source example is the fluentui [2] repo, which uses beachball to generate CHANGELOG.json and CHANGELOG.md files, and these files have very poor delta characteristics when comparing against versions across parent directories. | Stage | Pack Size | Repack Time | |-----------------------|-----------|-------------| | After clone | 694 MB | N/A | | --name-hash-version=1 | 438 MB | 728s | | --name-hash-version=2 | 168 MB | 142s | [2] https://github.com/microsoft/fluentui In this example, we see significant gains in the compressed packfile size as well as the time taken to compute the packfile. Using a collection of repositories that use the beachball tool, I was able to make similar comparisions with dramatic results. While the fluentui repo is public, the others are private so cannot be shared for reproduction. The results are so significant that I find it important to share here: | Repo | --name-hash-version=1 | --name-hash-version=2 | |----------|-----------------------|-----------------------| | fluentui | 440 MB | 161 MB | | Repo B | 6,248 MB | 856 MB | | Repo C | 37,278 MB | 6,755 MB | | Repo D | 131,204 MB | 7,463 MB | Future changes could include making --name-hash-version implied by a config value or even implied by default during a full repack. It is important to point out that the name hash value is stored in the .bitmap file format, so we must force --name-hash-version=1 when bitmaps are being read or written. Later, the bitmap format could be updated to be aware of the name hash version so deltas can be quickly computed across the bitmapped/not-bitmapped boundary. Signed-off-by: Derrick Stolee --- Documentation/git-pack-objects.txt | 32 ++++++++++++++++++- builtin/pack-objects.c | 49 +++++++++++++++++++++++++++--- t/t5300-pack-object.sh | 31 +++++++++++++++++++ 3 files changed, 106 insertions(+), 6 deletions(-) diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index e32404c6aae..7f69ae4855f 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -15,7 +15,8 @@ SYNOPSIS [--revs [--unpacked | --all]] [--keep-pack=] [--cruft] [--cruft-expiration=