[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 17:35:19 PST 2011


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


Kenneth Russell <kbr at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #119134|review?                     |review-
               Flag|                            |




--- Comment #18 from Kenneth Russell <kbr at google.com>  2011-12-14 17:35:19 PST ---
(From update of attachment 119134)
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.

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.

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

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.

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