On Tue, 2015-07-07 at 16:49 +1200, David Rowley wrote: > I might be mistaken here, but can't you just set context->mem_allocted > = 0; after that loop? > Or maybe it would be an improvement to only do the decrement > if MEMORY_CONTEXT_CHECKING is defined, then Assert() that > mem_allocated == 0 after the loop... > OK. Why not just always Assert that? >
Well, I thought the per loop decrement of the mem_allocated was wasteful, as shouldn't it always get to zero after the final loop anyway?
If so, for efficiency it would be better to zero it after the loop, but if we do that then we can't assert for zero.
> One other thing that I don't remember seeing discussed would be to > just store a List in each context which would store all of the > mem_allocated's that need to be updated during each allocation and > deallocation of memory. The list would be setup once when the context > is created. When a child context is setup we'd just loop up the parent > context chain and list_concat() all of the parent's lists onto the > child's lists. Would this method add too much overhead when a context > is deleted? Has this been explored already? > That's a good idea, as it would be faster than recursing. Also, the number of parents can't change, so we can just make an array, and that would be quite fast to update. Unless I'm missing something, this sounds like a nice solution. It would require more space in MemoryContextData, but that might not be a problem.
Oh an array is even better, but why more space? won't it just be a pointer to an array? It can be NULL if there's nothing to track. Sounds like it would be the same amount of space, at least on a 64 bit machine.
One thing to keep in mind is that I think if a parent is tracking memory, then a child will also need to track memory too, as when the child context is deleted, we'll need to decrement the parent's mem_allocated by that of all its child contexts