Re: [RFD PATCH 0/3] Use "object index" rather than pointers in the object hashing

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 17, 2007, 05:06 UTC
Message-ID: <Pine.LNX.4.64.0704162200420.5473@woody.linux-foundation.org>
In-Reply-To: <7vfy6zskb4.fsf@assigned-by-dhcp.cox.net>

On Mon, 16 Apr 2007, Junio C Hamano wrote:

> 
> I was thinking about revamping that "keeping track of all
> objects" stuff for some time, too, but in a different direction.
> Glad I have not touched that area ;-).

Well, I obviously shouldn't have touched it either. I introduced a bug in the first patch of the series (and the bug got removed by the third patch, but since the third patch was not worth applying yet, it means that patches 1 and 2 shouldn't be applied either, because of the bug).

The bug was that when I modified the generic object allocator framework to work with "union any_object", it would still do

	static struct name *block;		/* where "name" was "object" */
	...
	return block++;

so while we *allocated* a block of "union any_objects", the patch would then end up doling them out as "struct object" (which is *wrong* - we don't know which kind of object it is yet, so we need to allocate the maximum size!).

So it *should* have been

	static type *block;
	...
	return block++;

but it actually turns out that my timings seem to say that it's better to do the memset of the object just before returning it, so I changed it to use "xmalloc()" instead of "xcalloc()" for the block allocation, and then use

	static type *block;
	void *ret;
	...
	ret = block++;
	memset(ret, 0, sizeof(type));
	return ret;

instead.

> I think this makes sense, although the numbers are somewhat
> dissapointing.

Well, with just patches 1&2, the numbers don't go down, and the code looks cleaner (and it removes more lines than it adds). So let me re-send the series, and while I will re-send the final patch#3, only #1/#2 are actually meant to be considered for actual inclusion at this point.

		Linus