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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=73712





--- 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.