Re: struct hashmap_entry packing

From: Jeff King <peff@peff.net>
Date: Aug 5, 2014, 18:51 UTC
Message-ID: <20140805185137.GB10369@peff.net>
In-Reply-To: <53DFDCE2.9060406@gmail.com>

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

Show 13 quoted lines

> > 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