From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: Eric Wong <firstname.lastname@example.org> Cc: Jeff King <email@example.com>, firstname.lastname@example.org, Junio C Hamano <email@example.com> Subject: Re: [PATCH v2] server-info: do not list unlinked packs Date: Fri, 24 May 2019 09:34:21 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20190523172723.eny6smdt57zxau6z@dcvr> On Thu, May 23 2019, Eric Wong wrote: > Jeff King <email@example.com> wrote: >> On Thu, May 23, 2019 at 08:59:59AM +0000, Eric Wong wrote: >> >> > > We never delete entries from the in-memory packed_git list; a reprepare >> > > only adds to the list. You'd need to teach update_server_info() to >> > > ignore packs which are no longer present (or switch to exec-ing a >> > > separate update-server-info binary). >> > >> > Ah, checking files_exists() and setting a bit seems sufficient. >> >> Yes, though we do we even need to store the bit? > > I wanted to avoid the over-allocation, and I hit a bounds error > because I forgot to adjust num_pack as you mentioned > below. [...]ALLOC_GROW makes the whole thing much nicer. If you want to avoid over-allocation the last thing you want is ALLOC_GROW() :) I.e. see alloc_nr() in cache.h, we explicitly over-allocate with it. But as our extensive use of it shows this sort of pattern is the right trade-off, both in terms of performance on modern hardware, and code readability in cases like this where we're never going to realistically have to worry about memory pressure.
next prev parent reply other threads:[~2019-05-24 8:18 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-11 1:34 [PATCH] update-server-info: avoid needless overwrites Eric Wong 2019-05-11 7:35 ` Eric Sunshine 2019-05-11 20:47 ` [PATCH v2] " Eric Wong 2019-05-11 21:17 ` [PATCH] " Eric Wong 2019-05-11 23:37 ` Ævar Arnfjörð Bjarmason 2019-05-12 0:38 ` Eric Wong 2019-05-12 4:08 ` Jeff King 2019-05-12 7:16 ` Ævar Arnfjörð Bjarmason 2019-05-14 9:47 ` Jeff King 2019-05-14 10:33 ` Ævar Arnfjörð Bjarmason 2019-05-14 11:24 ` Jeff King 2019-05-14 11:57 ` Ævar Arnfjörð Bjarmason 2019-05-14 11:50 ` Eric Wong 2019-05-14 12:13 ` dumb HTTP things I want to do Eric Wong 2019-05-14 12:27 ` Jeff King 2019-05-14 12:19 ` [PATCH] update-server-info: avoid needless overwrites Ævar Arnfjörð Bjarmason 2019-05-14 12:29 ` Jeff King 2019-05-15 0:45 ` [PATCH 2/1] server-info: conditionally update on fetch Eric Wong 2019-05-15 20:38 ` [WIP] repack leaving stale entries in objects/info/packs Eric Wong 2019-05-15 21:48 ` Jeff King 2019-05-23 8:59 ` [PATCH] server-info: do not list unlinked packs Eric Wong 2019-05-23 10:24 ` Jeff King 2019-05-23 17:27 ` [PATCH v2] " Eric Wong 2019-05-24 6:05 ` Jeff King 2019-05-24 7:34 ` Ævar Arnfjörð Bjarmason [this message] 2019-05-13 23:17 ` [PATCH v3] update-server-info: avoid needless overwrites Eric Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2] server-info: do not list unlinked packs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).