1. 27 Oct, 2011 1 commit
  2. 01 Sep, 2011 1 commit
    • Junio C Hamano's avatar
      list-objects: pass callback data to show_objects() · 49473672
      Junio C Hamano authored
      The traverse_commit_list() API takes two callback functions, one to show
      commit objects, and the other to show other kinds of objects. Even though
      the former has a callback data parameter, so that the callback does not
      have to rely on global state, the latter does not.
      
      Give the show_objects() callback the same callback data parameter.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      49473672
  3. 25 Mar, 2011 1 commit
    • Duy Nguyen's avatar
      Improve tree_entry_interesting() handling code · 97d0b74a
      Duy Nguyen authored
      t_e_i() can return -1 or 2 to early shortcut a search. Current code
      may use up to two variables to handle it. One for saving return value
      from t_e_i temporarily, one for saving return code 2.
      
      The second variable is not needed. If we make sure the first variable
      does not change until the next t_e_i() call, then we can do something
      like this:
      
      int ret = 0;
      
      while (...) {
      	if (ret != 2) {
      		ret = t_e_i();
      		if (ret < 0) /* no longer interesting */
      			break;
      		if (ret == 0) /* skip this round */
      			continue;
      	}
      	/* ret > 0, interesting */
      }
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      97d0b74a
  4. 14 Mar, 2011 1 commit
  5. 03 Feb, 2011 1 commit
    • Elijah Newren's avatar
      Make rev-list --objects work together with pathspecs · cc5fa2fd
      Elijah Newren authored
      When traversing commits, the selection of commits would heed the list of
      pathspecs passed, but subsequent walking of the trees of those commits
      would not.  This resulted in 'rev-list --objects HEAD -- <paths>'
      displaying objects at unwanted paths.
      
      Have process_tree() call tree_entry_interesting() to determine which paths
      are interesting and should be walked.
      
      Naturally, this change can provide a large speedup when paths are specified
      together with --objects, since many tree entries are now correctly ignored.
      Interestingly, though, this change also gives me a small (~1%) but
      repeatable speedup even when no paths are specified with --objects.
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cc5fa2fd
  6. 13 Apr, 2009 2 commits
    • Linus Torvalds's avatar
      process_{tree,blob}: show objects without buffering · 8d2dfc49
      Linus Torvalds authored
      Here's a less trivial thing, and slightly more dubious one.
      
      I was looking at that "struct object_array objects", and wondering why we
      do that. I have honestly totally forgotten. Why not just call the "show()"
      function as we encounter the objects? Rather than add the objects to the
      object_array, and then at the very end going through the array and doing a
      'show' on all, just do things more incrementally.
      
      Now, there are possible downsides to this:
      
       - the "buffer using object_array" _can_ in theory result in at least
         better I-cache usage (two tight loops rather than one more spread out
         one). I don't think this is a real issue, but in theory..
      
       - this _does_ change the order of the objects printed. Instead of doing a
         "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
         over the commits (which puts all the root trees _first_ in the object
         list, this patch just adds them to the list of pending objects, and
         then we'll traverse them in that order (and thus show each root tree
         object together with the objects we discover under it)
      
         I _think_ the new ordering actually makes more sense, but the object
         ordering is actually a subtle thing when it comes to packing
         efficiency, so any change in order is going to have implications for
         packing. Good or bad, I dunno.
      
       - There may be some reason why we did it that odd way with the object
         array, that I have simply forgotten.
      
      Anyway, now that we don't buffer up the objects before showing them
      that may actually result in lower memory usage during that whole
      traverse_commit_list() phase.
      
      This is seriously not very deeply tested. It makes sense to me, it seems
      to pass all the tests, it looks ok, but...
      
      Does anybody remember why we did that "object_array" thing? It used to be
      an "object_list" a long long time ago, but got changed into the array due
      to better memory usage patterns (those linked lists of obejcts are
      horrible from a memory allocation standpoint). But I wonder why we didn't
      do this back then. Maybe there's a reason for it.
      
      Or maybe there _used_ to be a reason, and no longer is.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8d2dfc49
    • Linus Torvalds's avatar
      show_object(): push path_name() call further down · cf2ab916
      Linus Torvalds authored
      In particular, pushing the "path_name()" call _into_ the show() function
      would seem to allow
      
       - more clarity into who "owns" the name (ie now when we free the name in
         the show_object callback, it's because we generated it ourselves by
         calling path_name())
      
       - not calling path_name() at all, either because we don't care about the
         name in the first place, or because we are actually happy walking the
         linked list of "struct name_path *" and the last component.
      
      Now, I didn't do that latter optimization, because it would require some
      more coding, but especially looking at "builtin-pack-objects.c", we really
      don't even want the whole pathname, we really would be better off with the
      list of path components.
      
      Why? We use that name for two things:
       - add_preferred_base_object(), which actually _wants_ to traverse the
         path, and now does it by looking for '/' characters!
       - for 'name_hash()', which only cares about the last 16 characters of a
         name, so again, generating the full name seems to be just unnecessary
         work.
      
      Anyway, so I didn't look any closer at those things, but it did convince
      me that the "show_object()" calling convention was crazy, and we're
      actually better off doing _less_ in list-objects.c, and giving people
      access to the internal data structures so that they can decide whether
      they want to generate a path-name or not.
      
      This patch does that, and then for people who did use the name (even if
      they might do something more clever in the future), it just does the
      straightforward "name = path_name(path, component); .. free(name);" thing.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cf2ab916
  7. 09 Apr, 2009 1 commit
    • Björn Steinbrink's avatar
      process_{tree,blob}: Remove useless xstrdup calls · de551d47
      Björn Steinbrink authored
      The name of the processed object was duplicated for passing it to
      add_object(), but that already calls path_name, which allocates a new
      string anyway. So the memory allocated by the xstrdup calls just went
      nowhere, leaking memory.
      
      This reduces the RSS usage for a "rev-list --all --objects" by about 10% on
      the gentoo repo (fully packed) as well as linux-2.6.git:
      
          gentoo:
                          | old           | new
          ----------------|-------------------------------
          RSS             |       1537284 |       1388408
          VSZ             |       1816852 |       1667952
          time elapsed    |       1:49.62 |       1:48.99
          min. page faults|        417178 |        379919
      
          linux-2.6.git:
                          | old           | new
          ----------------|-------------------------------
          RSS             |        324452 |        292996
          VSZ             |        491792 |        460376
          time elapsed    |       0:14.53 |       0:14.28
          min. page faults|         89360 |         81613
      Signed-off-by: default avatarBjörn Steinbrink <B.Steinbrink@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      de551d47
  8. 08 Apr, 2009 1 commit
    • Christian Couder's avatar
      list-objects: add "void *data" parameter to show functions · 11c211fa
      Christian Couder authored
      The goal of this patch is to get rid of the "static struct rev_info
      revs" static variable in "builtin-rev-list.c".
      
      To do that, we need to pass the revs to the "show_commit" function
      in "builtin-rev-list.c" and this in turn means that the
      "traverse_commit_list" function in "list-objects.c" must be passed
      functions pointers to functions with 2 parameters instead of one.
      
      So we have to change all the callers and all the functions passed
      to "traverse_commit_list".
      
      Anyway this makes the code more clean and more generic, so it
      should be a good thing in the long run.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      11c211fa
  9. 19 Feb, 2008 1 commit
  10. 10 Nov, 2007 1 commit
    • Shawn O. Pearce's avatar
      Fix memory leak in traverse_commit_list · 295dd2ad
      Shawn O. Pearce authored
      If we were listing objects too then the objects were buffered in an
      array only reachable from a stack allocated structure.  When this
      function returns that array would be leaked as nobody would have
      a reference to it anymore.
      
      Historically this hasn't been a problem as the primary user of
      traverse_commit_list() (the noble git-rev-list) would terminate
      as soon as the function was finished, thus allowing the operating
      system to cleanup memory.  However we have been leaking this data
      in git-pack-objects ever since that program learned how to run the
      revision listing internally, rather than relying on reading object
      names from git-rev-list.
      
      To better facilitate reuse of traverse_commit_list during other
      builtin tools (such as git-fetch) we shouldn't leak temporary memory
      like this and instead we need to clean up properly after ourselves.
      Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      295dd2ad
  11. 22 May, 2007 1 commit
  12. 14 Apr, 2007 1 commit
  13. 13 Apr, 2007 1 commit
  14. 21 Mar, 2007 1 commit
  15. 07 Sep, 2006 2 commits