Am 04.10.2018 um 08:48 schrieb Jeff King: > On Thu, Oct 04, 2018 at 07:56:44AM +0200, René Scharfe wrote: > >>> 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. > > It's a little awkward because the lazy load happens in a conditional. > You can fully encapsulate it like the patch below, but I actually don't > think it's really helping readability.
*Shudder* >>> 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.. > > Unless we know something is a performance win to inline, I'd generally > prefer not to. Agreed. > For a case like this with auto-generated functions, I'm mostly worried > about bloating the compiled code. Either with a bunch of inlined > non-trivial functions, or cases where the compiler says "this is too big > to inline" and generates an anonymous file-scope function, but we end up > with a bunch of duplicates, because we're generating the same functions > in a bunch of C files. The _iter_ functions look harmless in this regard, as the only use small functions that are not even type-specific. oidset_init() would better be moved to oidset.c, as the code for resizing is quite big. René
