On Thursday 27 August 2009, Johan Herland wrote: > On Thursday 27 August 2009, Alex Riesen wrote: > > On Thu, Aug 27, 2009 at 03:43, Johan Herland<johan@xxxxxxxxxxx> wrote: > > > When allocating a new memory pool, the older pool is leaked, but this > > > is no worse than the current situation, where (pretty much) all > > > leaf_nodes are leaked anyway. > > > > Could you return the unused nodes back into the mempool? > > By making the pool a preallocated list, perhaps? > > Yes, maintaining a free-list is certainly possible. However, the number > of free()d leaf_nodes is relatively small (only subtree entries are > free()d after unpacking them into the tree structure), so I'm not sure it > pays off, runtime-wise. I played around with the free-list idea, but it cost more than the memory pooling code saved in the first place. I'm leaning towards dropping the whole memory pooling idea, as the small run-time improvement is probably not worth the added complexity. We'll see. I'll re-evaluate once I've refactored the code according to the other threads of this discussion. > > And then it is trivial to provide a deallocation function for the > > mempool, which something really concerned about the memleak can call > > (like when or if libgit get more usable in an application context). > > Yes, I plan to provide a free_notes() function that free()s all the > memory associated with the notes data structure. This would of course > keep references to all the mempools, and deallocate them (along with all > the int_nodes). This still stands, of course. Should be part of the next iteration. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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