[chromium-dev] Re: Recommendations for string data type
On Nov 7, 2009, at 3:10 PM, Erik Corry wrote: V8 strings get moved by the garbage collector so it's probably unrealistic to access the internal strings externally. Yes. Using V8 to back a StringImpl would require doing something about the API call that returns a direct pointer to the characters. (I have a couple of ideas.) On the other hand V8 supports strings backed by an external immutable utf16 or ASCii character buffer (no utf-8!). This is already heavily used in the binding layer. The problem with this is that V8 still allocates the string first, and then WebCore makes a copy. Even though V8 points to the WebCore string afterwards, the memory for the original V8 string is still in the V8 heap until the next GC. So this has an effect on footprint. In addition, the time to copy the strings is definitely a hot spot in the Dromaeo DOM benchmarks. While utf8 can be useful for interchange and storage it is a major pain for immutable strings (how to get the nth character?) and no use at all for mutable string buffers. Agreed. ISO-8859-1 (aka CP1252) would be a saner choice. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Recommendations for string data type
On Nov 9, 2009, at 2:22 PM, Erik Corry wrote: How big are the strings we are talking about here on average? In Dromaeo? I haven't checked; I was focusing on other metrics when I ran those tests. You could run the four DOM Core benchmarks and instrument the code to find out. The DOM Query subtest is the one where Chrome really gets its butt kicked by Safari (2x as fast!). I don't have the profile dumps anymore, unfortunately, but my recollection is that Chrome spent at least 10% of the time converting strings. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Recommendations for string data type
Thanks for all the responses. Just ot give some context (as some of you asked) I came across this recently when working on string cleanup in bookmark sync code. The sync protocol uses UTF8 and it interacts with bookmarks which is all wstrings. syncapi.h is the interface on top of sync engine that provides and interface to the code on top (we call it glue) to go back and forth from bookmark model and sync model. So in this case the choice was easy - to use wstrings in syncapi interface since that's what's consumed/produced by callers of the API. My main observation (which surprised me) was that bookmark model uses wstrings, but Scoot cleared to me that it has to be moed to string16 one day. I signed up for doing that next quarter :). Thanks again for nice pointers and providing good insight into this. -Munjal On Fri, Nov 6, 2009 at 4:16 PM, Peter Kasting pkast...@google.com wrote: On Fri, Nov 6, 2009 at 4:08 PM, Jens Alfke s...@google.com wrote: I have been looking at WebCore::StringImpl a lot lately, and I would really like to make it a bit more abstract [i.e. virtual methods] so it could support multiple backing store implementations tuned for different strings. WebKit code has allergies to virtual functions. If you want to do this, you'll need to come armed with perf data that shows that there is absolutely no speed hit. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
