On Sat, 4 Nov 2006, Robin Rosenberg wrote: > > The overhead is eigth bytes per object on a 32-bit platform and 16 on a 64-bit > platform for Sun's JDK. The granularity is eight bytes in both cases. Note that the object structure itself is just 24 bytes (regardless of whether we're on a 32-bit or 64-bit architecture). In addition to that, we need one pointer per hash entry, and in order to keep the hash list size down we need that hash array to be about 25% free, so say 1.5 pointers per object: ~6 bytes or ~12 bytes depending on whether it's a 32- or 64-bit architecture. So 8 or 16 bytes overhead per object is roughly a 25% or 50% pure overhead. In contrast, right now we have pretty much _zero_ overhead (we do end up having some malloc cost, but since we batch them, it's on the order of a few bytes per _thousand_ objects, so we're talking fractions of a percent). Of course, the memory footprint isn't _just_ the objects, but it's a big part of it, for some important apps (not just repack, but git-send-pack obviously also has this). So on a git server, keeping the memory use down is likely the #1 concern - even if the server might have gigabytes of RAM. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html