Hi Ram, Ramkumar Ramachandra wrote: > I've never used talloc. What basis can we use for the comparison? Ah, a little explanation is in order. You see, I read the commit message, having just looked at the treap implementation, read the word “allocator”, and decided that a mini-malloc was exactly the sort of thing I did not want to read right then. Hence the silly comment about some allocator that pools memory for heterogeneous-sized blocks (which is very nice and convenient, but not so relevant!). Sorry --- I should not have been so lazy. In fact, this patch just maintains a growing array of never-freed fixed-size blocks. It is very similar to the existing alloc.c but with some small differences: . uses a single memory area that grows with realloc, so it can be freed for valgrind-cleanness if one wants. . grows a little more aggressively, as David pointed out And it is much simpler than I was thinking, so honestly, I don’t even mind the code duplication so much. For interest, the analogous CCAN module is http://ccan.ozlabs.org/info/block_pool.html > On a related note, note that while compiling, a lot of > unused functions are generated which pop up as compiler warnings Maybe __attribute__((__unused__)) could work. Sorry for the nonsense, Jonathan -- 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