git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Optimization for git-rev-list --objects

From
Linus Torvalds <torvalds@osdl.org>
Date
Feb 12, 2006, 02:19 UTC
Message-ID
<Pine.LNX.4.64.0602111803350.3691@g5.osdl.org>
In-Reply-To
<87slqpg11q.fsf@wine.dyndns.org>
On Sat, 11 Feb 2006, Alexandre Julliard wrote:
Show 8 quoted lines
> 
> When building a large list of objects, most of the time is spent in
> created_object() inserting the objects in the sorted list. This patch
> splits the list in 256 sublists to reduce the impact of the O(n^2)
> list insertion.
> 
> On the WineHQ repository (220,000 objects), the patch reduces the time
> needed for a 'git-rev-list --objects HEAD' from 2 minutes to 20 seconds.
Goodie. However, I wonder if we care about the sorting at _all_.

The sorting really only helps "find_object()", and the thing is, we could certainly do that other ways too. Keeping a sorted list is kind of senseless, when the data is so amenable to be kept in a tree.

We could add left/right pointers to each object, and just keep them in a tree. We probably don't even need any fancy balancing, since hashing means that we could just keep the first object we ever allocate as the root, and things should normally be pretty damn balanced.

Then we could do:
	static struct object *root = NULL;
	static struct object **lookup_object_position(unsigned char *sha1)
	{
		struct object **p = &root;
		for (;;) {
			struct object *object = *p;
			int sign;
			if (!object)
				break;
			sign = memcmp(sha1, object->sha1, 20)
			if (!sign)
				break;
			p = &object->left;
			if (sign < 0)
				continue;
			p = &object->right;
		}
		return p;
	}
and now we _trivially_ have:
	struct object *lookup_object(unsigned char *sha1)
	{
		return *lookup_object_position(unsigned char *sha1);
	}
	void created_object(struct object **pos, unsigned char *sha1, struct object *n)
	{
		memcpy(n->sha1, sha1, 20);
		*pos = n;
	}
and the "lookup_or_create()" functions would become
	struct tag *lookup_tag(unsigned char *sha1)
	{
		struct object **p = lookup_object_position(sha1);
		struct object *object;
		object = *p;
		if (!object) {
			struct tag *ret = xmalloc(sizeof(struct tag));
			memset(ret, 0, sizeof(struct tag));
			created_object(p, sha1, &ret->object);
			ret->object.type = tag_type;
			return ret;
		}
		if (!object->type)
			obj->type = tag_type;
		if (object->type != tag_type) {
			error("Object %s is a %s, not a tag",
				sha1_to_hex(sha1), obj->type);
			return NULL;
		}
		return (struct tag *)obj;
	}
etc etc.

Hmm? That would be a lot faster than what we have now, I suspect, and none of the ops are expensive.

Anybody want to try this approach?
		Linus
Previous: Junio C HamanoNext: Junio C Hamano
Message 12 of 21 in “Optimization for git-rev-list --objects”
  1. Optimization for git-rev-list --objectsAlexandre Julliard, Feb 11, 2006
  2. Use a hashtable for objects instead of a sorted listJohannes Schindelin, Feb 12, 2006
  3. Junio C HamanoFeb 12, 2006
  4. Alexandre JulliardFeb 12, 2006
  5. Junio C HamanoFeb 12, 2006
  6. Johannes SchindelinFeb 12, 2006
  7. Florian WeimerFeb 12, 2006
  8. ***DONTUSE*** Re: [PATCH] Use a hashtable for objects instead of a sorted listJunio C Hamano, Feb 12, 2006
  9. ***DONTUSE*** Re: [PATCH] Use a hashtable for objects instead of a sorted listJunio C Hamano, Feb 12, 2006
  10. Johannes SchindelinFeb 12, 2006
  11. Junio C HamanoFeb 12, 2006
  12. Linus TorvaldsFeb 12, 2006
  13. Junio C HamanoFeb 12, 2006
  14. binary-tree-based objects.Junio C Hamano, Feb 12, 2006
  15. Linus TorvaldsFeb 12, 2006
  16. Linus TorvaldsFeb 12, 2006
  17. Linus TorvaldsFeb 12, 2006
  18. Junio C HamanoFeb 12, 2006
  19. Junio C HamanoFeb 12, 2006
  20. Linus TorvaldsFeb 12, 2006
  21. Linus TorvaldsFeb 12, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.