[Webkit-unassigned] [Bug 73712] PODIntervalTree takes 1.7MB memory on www.nytimes.com

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 14 18:51:14 PST 2011


--- Comment #19 from Yongjun Zhang <yongjun_zhang at apple.com>  2011-12-14 18:51:13 PST ---
(In reply to comment #18)
> (From update of attachment 119134 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=119134&action=review
> > Source/WebCore/platform/PODFreeListArena.h:33
> > +class PODFreeListArena : public PODArena {
> This is a step in the right direction but doesn't address the basic problem in the last review. This class still allows allocation and freeing of different sizes.
> My thought was to parameterize PODFreeListArena on the one type of object it knows how to allocate. I would use private inheritance from PODArena. The PODFreeListArena's allocateObject() methods shouldn't take the first "class T" template argument. Change PODRedBlackTree to accept a PODFreeListArena<T> rather than a PODArena.

thanks,  this should work!  I was trying to keep the change in PODRedBlackTree small, but I didn't realize a PODRedBlackTree will always ask its arena to allocate objects of the same size.

> The challenge will be to figure out how to describe the type parameter. It will be a Node<T> where T is the type parameter of the RedBlackTree. Currently Node is an internal concept to RedBlackTree. Perhaps you can expose it with a public typedef.

Yeah, it would be a bit awkward to declare the interval arena in Document as something like:

PODFreeListArena<PODRedBlackTree<int, FloatingObject*>::Node>

> The solution I'm outlining will also allow getting rid of the virtual allocate and free functions, which are undesirable.

true, and we can also avoid the overhead of virtual function calls.

> Another solution could be to configure PODFreeListArena so that it can only allocate objects of a certain size, and sprinkle assertions throughout the code. This is gross though and I would rather find a solution that uses the type system to enforce correct usage.

This is essential what the current patch is doing (without assertions though).  Anyway, I will try the approach you suggested and see how it goes.  thanks!

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list