From: "René Scharfe" <l.s.r@web.de>
To: Jeff King <peff@peff.net>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 2/2] oidset: use khash
Date: Thu, 4 Oct 2018 07:56:44 +0200 [thread overview]
Message-ID: <d17f104e-7cc2-5e73-78c9-6c268f9ec5b2@web.de> (raw)
In-Reply-To: <20181003194051.GB20709@sigill.intra.peff.net>
Am 03.10.2018 um 21:40 schrieb Jeff King:
> On Wed, Oct 03, 2018 at 03:16:39PM +0200, René Scharfe wrote:
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index 75047a4b2a..a839315726 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -536,7 +536,7 @@ static int tip_oids_contain(struct oidset *tip_oids,
>> * add to "newlist" between calls, the additions will always be for
>> * oids that are already in the set.
>> */
>> - if (!tip_oids->map.map.tablesize) {
>> + if (!tip_oids->set.n_buckets) {
>> add_refs_to_oidset(tip_oids, unmatched);
>> add_refs_to_oidset(tip_oids, newlist);
>> }
>
> This is a little intimate with the implementation of khash, but I think
> it's probably OK (and really no worse than what was there before).
>
> As the comment above notes, I think we're really looking at the case
> where this gets populated on the first call, but not subsequent ones. It
> might be less hacky to use a "static int initialized" here. Or if we
> want to avoid hidden globals, put the logic into filter_refs() to decide
> when to populate.
Right. I'd prefer the latter, but was unable to find a nice way that
still populates the oidset lazily. It's certainly worth another look,
and a separate series.
>> diff --git a/oidset.h b/oidset.h
>> index 40ec5f87fe..4b90540cd4 100644
>> --- a/oidset.h
>> +++ b/oidset.h
>> [...]
>> +KHASH_INIT(oid, struct object_id, int, 0, oid_hash, oid_equal)
>
> This will declare these "static inline". Our other major "macros become
> inline functions" code is commit-slab.h, and there we found it necessary
> to add MAYBE_UNUSED. I wonder if we ought to be doing the same here (I
> don't get any warnings, but I suspect sparse might complain).
I doubt it (but didn't check) because khash.h defines kh_clear_##name(),
which we don't use it anywhere and there have been no complaints so far.
And if we wanted to add MAYBE_UNUSED then the right place for that would
be in KHASH_INIT, no?
> It might be nice if these functions could hide inside oidset.c (and just
> declare the struct here). It looks like we might be able to do that with
> __KHASH_TYPE(), but the double-underscore implies that we're not
> supposed to. ;)
>
> I guess we also use a few of them in our inlines here. I'm not 100% sure
> that oidset_* needs to be inlined either, but this is at least a pretty
> faithful conversion of the original.
We could inline all of the oidset functions, following the spirit of
klib/khash.h.
Or we could uninline all of them and then may be able to clean up
oidset.h by using KHASH_DECLARE. Perhaps we'd need to guard with an
"#ifndef THIS_IS_OIDSET_C" or similar to avoid a clash with KHASH_INIT.
Not sure if any of that would be a worthwhile improvement..
René
next prev parent reply other threads:[~2018-10-04 5:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 13:11 [PATCH v2 0/2] oidset: use khash René Scharfe
2018-10-03 13:12 ` [PATCH v2 1/2] khash: factor out kh_release_* René Scharfe
2018-10-03 13:16 ` [PATCH v2 2/2] oidset: use khash René Scharfe
2018-10-03 19:40 ` Jeff King
2018-10-04 5:56 ` René Scharfe [this message]
2018-10-04 6:48 ` Jeff King
2018-10-04 6:50 ` Jeff King
2018-10-04 15:05 ` René Scharfe
2018-10-04 15:05 ` [PATCH v3 0/5] " René Scharfe
2018-10-04 15:09 ` [PATCH v3 1/5] fetch-pack: factor out is_unmatched_ref() René Scharfe
2018-10-04 15:09 ` [PATCH v3 2/5] fetch-pack: load tip_oids eagerly iff needed René Scharfe
2018-10-04 21:38 ` Jonathan Tan
2018-10-04 22:11 ` René Scharfe
2018-10-05 20:13 ` René Scharfe
2018-10-04 22:14 ` Jeff King
2018-10-04 22:52 ` Jonathan Tan
2018-10-04 23:18 ` Jeff King
2018-10-04 22:07 ` Jeff King
2018-10-05 20:13 ` René Scharfe
2018-10-05 20:27 ` Jeff King
2018-10-05 21:22 ` René Scharfe
2018-10-05 21:47 ` Jeff King
2018-10-04 15:10 ` [PATCH v3 3/5] khash: factor out kh_release_* René Scharfe
2018-10-04 15:13 ` [PATCH v3 4/5] oidset: use khash René Scharfe
2018-10-04 15:14 ` [PATCH 5/5] oidset: uninline oidset_init() René Scharfe
2018-10-04 22:15 ` [PATCH v3 0/5] oidset: use khash Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d17f104e-7cc2-5e73-78c9-6c268f9ec5b2@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).