Re: struct hashmap_entry packing

[Jeff King <peff@peff.net>]

On Mon, Aug 04, 2014 at 09:20:02PM +0200, Karsten Blees wrote:

> > I don't see any reason to avoid the packed attribute, if it helps us. As
> > you noted, anything using __attribute__ probably supports it, and if
> > not, we can conditionally #define PACKED_STRUCT or something, like we do
> > for NORETURN. Since it's purely an optimization, if another compiler
> > doesn't use it, no big deal.
> > 
> > That being said, I don't know if those padding bytes are actually
> > causing a measurable slowdown. It may not even be worth the trouble.
> > 
> 
> Its not about performance (or correctness, in case of platforms that don't
> support unaligned read), just about saving memory (e.g. mapping int to int
> requires 24 bytes per entry, vs. 16 with packed structs).

The biggest things we might map are probably one entry per-object. So in
a repository like linux.git, we're talking about 32MB in the worst case.
That's not nothing, but it's also not the end of the world. I'd be more
concerned with how that trashes the cache (and consequently causes
slowdown) than somebody running out of memory.

So my general opinion is that if it's easy to get the space back, great.
But if it creates a maintenance hassle, it's not worth the effort.

That said, I really don't think it would be much maintenance hassle to
mark the hashmap_entry as packed, and compilers can either handle it or
not.

-Peff