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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html