1. 19 Jan, 2010 1 commit
  2. 17 Apr, 2007 1 commit
  3. 27 Feb, 2007 1 commit
    • Nicolas Pitre's avatar
      convert object type handling from a string to a number · 21666f1a
      Nicolas Pitre authored
      We currently have two parallel notation for dealing with object types
      in the code: a string and a numerical value.  One of them is obviously
      redundent, and the most used one requires more stack space and a bunch
      of strcmp() all over the place.
      
      This is an initial step for the removal of the version using a char array
      found in object reading code paths.  The patch is unfortunately large but
      there is no sane way to split it in smaller parts without breaking the
      system.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      21666f1a
  4. 20 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      simplify inclusion of system header files. · 85023577
      Junio C Hamano authored
      This is a mechanical clean-up of the way *.c files include
      system header files.
      
       (1) sources under compat/, platform sha-1 implementations, and
           xdelta code are exempt from the following rules;
      
       (2) the first #include must be "git-compat-util.h" or one of
           our own header file that includes it first (e.g. config.h,
           builtin.h, pkt-line.h);
      
       (3) system headers that are included in "git-compat-util.h"
           need not be included in individual C source files.
      
       (4) "git-compat-util.h" does not have to include subsystem
           specific header files (e.g. expat.h).
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      85023577
  5. 13 Jul, 2006 1 commit
  6. 20 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Add specialized object allocator · 855419f7
      Linus Torvalds authored
      This creates a simple specialized object allocator for basic
      objects.
      
      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: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      855419f7
  7. 18 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Shrink "struct object" a bit · 885a86ab
      Linus Torvalds authored
      This shrinks "struct object" by a small amount, by getting rid of the
      "struct type *" pointer and replacing it with a 3-bit bitfield instead.
      
      In addition, we merge the bitfields and the "flags" field, which
      incidentally should also remove a useless 4-byte padding from the object
      when in 64-bit mode.
      
      Now, our "struct object" is still too damn large, but it's now less
      obviously bloated, and of the remaining fields, only the "util" (which is
      not used by most things) is clearly something that should be eventually
      discarded.
      
      This shrinks the "git-rev-list --all" memory use by about 2.5% on the
      kernel archive (and, perhaps more importantly, on the larger mozilla
      archive). That may not sound like much, but I suspect it's more on a
      64-bit platform.
      
      There are other remaining inefficiencies (the parent lists, for example,
      probably have horrible malloc overhead), but this was pretty obvious.
      
      Most of the patch is just changing the comparison of the "type" pointer
      from one of the constant string pointers to the appropriate new TYPE_xxx
      small integer constant.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      885a86ab
  8. 04 Apr, 2006 1 commit
  9. 07 Jan, 2006 1 commit
    • Junio C Hamano's avatar
      [PATCH] Compilation: zero-length array declaration. · 8f1d2e6f
      Junio C Hamano authored
      ISO C99 (and GCC 3.x or later) lets you write a flexible array
      at the end of a structure, like this:
      
      	struct frotz {
      		int xyzzy;
      		char nitfol[]; /* more */
      	};
      
      GCC 2.95 and 2.96 let you to do this with "char nitfol[0]";
      unfortunately this is not allowed by ISO C90.
      
      This declares such construct like this:
      
      	struct frotz {
      		int xyzzy;
      		char nitfol[FLEX_ARRAY]; /* more */
      	};
      
      and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
      empty for others.
      
      If you are using a C90 C compiler, you should be able
      to override this with CFLAGS=-DFLEX_ARRAY=1 from the
      command line of "make".
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      8f1d2e6f
  10. 08 Jun, 2005 1 commit
  11. 20 May, 2005 1 commit
  12. 06 May, 2005 1 commit
    • Nicolas Pitre's avatar
      [PATCH] don't load and decompress objects twice with parse_object() · bd2c39f5
      Nicolas Pitre authored
      It turns out that parse_object() is loading and decompressing given
      object to free it just before calling the specific object parsing
      function which does mmap and decompress the same object again. This
      patch introduces the ability to parse specific objects directly from a
      memory buffer.
      
      Without this patch, running git-fsck-cache on the kernel repositorytake:
      
      	real    0m13.006s
      	user    0m11.421s
      	sys     0m1.218s
      
      With this patch applied:
      
      	real    0m8.060s
      	user    0m7.071s
      	sys     0m0.710s
      
      The performance increase is significant, and this is kind of a
      prerequisite for sane delta object support with fsck.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bd2c39f5
  13. 04 May, 2005 1 commit
  14. 28 Apr, 2005 1 commit
  15. 26 Apr, 2005 1 commit
  16. 24 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      fsck-cache: notice missing "blob" objects. · 4728b861
      Linus Torvalds authored
      We should _not_ mark a blob object "parsed" just because we
      looked it up: it gets marked that way only once we've actually
      seen it. Otherwise we can never notice a missing blob.
      4728b861
  17. 18 Apr, 2005 1 commit