I think we have a StringBuilder class that is optimized for building string incrementally. Other code uses Vector<UChar> and String::adopt. Maybe we should optimize the hot spots instead of changing Strings everywhere? Adam On Thu, Dec 3, 2009 at 8:32 AM, Zoltan Herczeg <zherczeg@inf.u-szeged.hu> wrote:

Hi,

according to my measurements, a large chunk of WebKit memory consumption comes from WebCore::TextResourceDecoder::decode (loader/TextResourceDecoder.cpp:818) which calls String::append (String.cpp:82). The comment there says:

 // FIXME: This is extremely inefficient.

I would volunteer to rewrite the code (especially reducing the memory consumption), but first, I would like to hear your opinion how can we make the string handling of WebKit better.

Zoltan

_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

On Dec 3, 2009, at 8:32 AM, Zoltan Herczeg wrote:

Hi,

according to my measurements, a large chunk of WebKit memory consumption comes from WebCore::TextResourceDecoder::decode (loader/TextResourceDecoder.cpp:818) which calls String::append (String.cpp:82). The comment there says:

// FIXME: This is extremely inefficient.

I would volunteer to rewrite the code (especially reducing the memory consumption), but first, I would like to hear your opinion how can we make the string handling of WebKit better.

I believe the inefficiency there is speed, not space. Vector<UChar> or StringBuilder as an alternative would reduce potential for excess reallocation but I don't think they would reduce memory use. In fact memory use may go up. (As a side note I was unable to find the String::append call in TextResourceDecoder. I think a lot of memory use is blamed on the decoder because we keep around a decoded copy of every text-based subresource. In theory we could drop the decoded version under memory pressure since it can be re-decoded from the original data on demand. Regards, Maciej