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 vger.kernel.org
More majordomo info at http://vge
r.kernel.org/majordomo-info.html
|