aboutsummaryrefslogtreecommitdiff
path: root/list-objects.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-04-10 17:27:58 -0700
committerJunio C Hamano <gitster@pobox.com>2009-04-12 17:28:31 -0700
commit8d2dfc49b199c7da6faefd7993630f24bd37fee0 (patch)
treef1e54aab7902cde544d1ac8ea41401fdea431184 /list-objects.c
parent213152688c85a0e4d591abc1c10b7c279ffefb99 (diff)
downloadgit-8d2dfc49b199c7da6faefd7993630f24bd37fee0.tar.gz
git-8d2dfc49b199c7da6faefd7993630f24bd37fee0.tar.xz
process_{tree,blob}: show objects without buffering
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: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'list-objects.c')
-rw-r--r--list-objects.c35
1 files changed, 18 insertions, 17 deletions
diff --git a/list-objects.c b/list-objects.c
index dd243c7c6..5a4af62bd 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -10,7 +10,7 @@
static void process_blob(struct rev_info *revs,
struct blob *blob,
- struct object_array *p,
+ show_object_fn show,
struct name_path *path,
const char *name)
{
@@ -23,7 +23,7 @@ static void process_blob(struct rev_info *revs,
if (obj->flags & (UNINTERESTING | SEEN))
return;
obj->flags |= SEEN;
- add_object(obj, p, path, name);
+ show(obj, path_name(path, name));
}
/*
@@ -50,7 +50,7 @@ static void process_blob(struct rev_info *revs,
*/
static void process_gitlink(struct rev_info *revs,
const unsigned char *sha1,
- struct object_array *p,
+ show_object_fn show,
struct name_path *path,
const char *name)
{
@@ -59,7 +59,7 @@ static void process_gitlink(struct rev_info *revs,
static void process_tree(struct rev_info *revs,
struct tree *tree,
- struct object_array *p,
+ show_object_fn show,
struct name_path *path,
const char *name)
{
@@ -77,7 +77,7 @@ static void process_tree(struct rev_info *revs,
if (parse_tree(tree) < 0)
die("bad tree object %s", sha1_to_hex(obj->sha1));
obj->flags |= SEEN;
- add_object(obj, p, path, name);
+ show(obj, path_name(path, name));
me.up = path;
me.elem = name;
me.elem_len = strlen(name);
@@ -88,14 +88,14 @@ static void process_tree(struct rev_info *revs,
if (S_ISDIR(entry.mode))
process_tree(revs,
lookup_tree(entry.sha1),
- p, &me, entry.path);
+ show, &me, entry.path);
else if (S_ISGITLINK(entry.mode))
process_gitlink(revs, entry.sha1,
- p, &me, entry.path);
+ show, &me, entry.path);
else
process_blob(revs,
lookup_blob(entry.sha1),
- p, &me, entry.path);
+ show, &me, entry.path);
}
free(tree->buffer);
tree->buffer = NULL;
@@ -134,16 +134,20 @@ void mark_edges_uninteresting(struct commit_list *list,
}
}
+static void add_pending_tree(struct rev_info *revs, struct tree *tree)
+{
+ add_pending_object(revs, &tree->object, "");
+}
+
void traverse_commit_list(struct rev_info *revs,
void (*show_commit)(struct commit *),
- void (*show_object)(struct object_array_entry *))
+ void (*show_object)(struct object *, const char *))
{
int i;
struct commit *commit;
- struct object_array objects = { 0, 0, NULL };
while ((commit = get_revision(revs)) != NULL) {
- process_tree(revs, commit->tree, &objects, NULL, "");
+ add_pending_tree(revs, commit->tree);
show_commit(commit);
}
for (i = 0; i < revs->pending.nr; i++) {
@@ -154,25 +158,22 @@ void traverse_commit_list(struct rev_info *revs,
continue;
if (obj->type == OBJ_TAG) {
obj->flags |= SEEN;
- add_object_array(obj, name, &objects);
+ show_object(obj, name);
continue;
}
if (obj->type == OBJ_TREE) {
- process_tree(revs, (struct tree *)obj, &objects,
+ process_tree(revs, (struct tree *)obj, show_object,
NULL, name);
continue;
}
if (obj->type == OBJ_BLOB) {
- process_blob(revs, (struct blob *)obj, &objects,
+ process_blob(revs, (struct blob *)obj, show_object,
NULL, name);
continue;
}
die("unknown pending object %s (%s)",
sha1_to_hex(obj->sha1), name);
}
- for (i = 0; i < objects.nr; i++)
- show_object(&objects.objects[i]);
- free(objects.objects);
if (revs->pending.nr) {
free(revs->pending.objects);
revs->pending.nr = 0;