Commits on Apr 17, 2007
  1. Clean up object creation to use more common code

    torvalds authored and Junio C Hamano committed Apr 17, 2007
    This replaces the fairly odd "created_object()" function that did _most_
    of the object setup with a more complete "create_object()" function that
    also has a more natural calling convention.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. Use proper object allocators for unknown object nodes too

    torvalds authored and Junio C Hamano committed Apr 17, 2007
    We used to use a different allocator scheme for when we didn't know the
    object type.  That meant that objects that were created without any
    up-front knowledge of the type would not go through the same allocation
    paths as normal object allocations, and would miss out on the statistics.
    But perhaps more importantly than the statistics (that are useful when
    looking at memory usage but not much else), if we want to make the
    object hash tables use a denser object pointer representation, we need
    to make sure that they all go through the same blocking allocator.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Aug 2, 2006
  1. Add NO_C99_FORMAT to support older compilers.

    Ramsay Allan Jones Junio C Hamano
    Ramsay Allan Jones authored and Junio C Hamano committed Jul 30, 2006
    The NO_C99_FORMAT macro allows compilers that lack support for the
    ll,hh,j,z,t size specifiers (eg. gcc 2.95.2) to adapt the code to avoid
    runtime errors in the formatted IO functions.
    Signed-off-by: Ramsay Allan Jones <>
    Signed-off-by: Junio C Hamano <>
Commits on Jun 20, 2006
  1. Add specialized object allocator

    Linus Torvalds Junio C Hamano
    Linus Torvalds authored and Junio C Hamano committed Jun 19, 2006
    This creates a simple specialized object allocator for basic
    This avoids wasting space with malloc overhead (metadata and
    extra alignment), since the specialized allocator knows the
    alignment, and that objects, once allocated, are never freed.
    It also allows us to track some basic statistics about object
    allocations. For example, for the mozilla import, it shows
    object usage as follows:
         blobs:   627629 (14710 kB)
         trees:  1119035 (34969 kB)
       commits:   196423  (8440 kB)
          tags:     1336    (46 kB)
    and the simpler allocator shaves off about 2.5% off the memory
    footprint off a "git-rev-list --all --objects", and is a bit
    faster too.
    [ Side note: this concludes the series of "save memory in object storage".
      The thing is, there simply isn't much more to be saved on the objects.
      Doing "git-rev-list --all --objects" on the mozilla archive has a final
      total RSS of 131498 pages for me: that's about 513MB. Of that, the
      object overhead is now just 56MB, the rest is going somewhere else (put
      another way: the fact that this patch shaves off 2.5% of the total
      memory overhead, considering that objects are now not much more than 10%
      of the total shows how big the wasted space really was: this makes
      object allocations much more memory- and time-efficient).
      I haven't looked at where the rest is, but I suspect the bulk of it is
      just the pack-file loading. It may be that we should pack the tree
      objects separately from the blob objects: for git-rev-list --objects, we
      don't actually ever need to even look at the blobs, but since trees and
      blobs are interspersed in the pack-file, we end up not being dense in
      the tree accesses, so we end up looking at more pages than we strictly
      need to.
      So with a 535MB pack-file, it's entirely possible - even likely - that
      most of the remaining RSS is just the mmap of the pack-file itself. We
      don't need to map in _all_ of it, but we do end up mapping a fair
      amount. ]
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>