It looks to me like WriteToFlat is called once, to write to the external resource, in the fixed case, and thatit is called twice, once for the external resource and once for the ToCString in the debug assert, in the broken case. If that is the dominant cost, then why is the time increasing by a factor of 4 or more? The time used should at most double. I think the memcmp and the allocation should not be that significant. So I am wondering if all the extra time is used in that call to ToCString, and if so, why is it so much slower than converting to external, which has to do the same work. The whole thing is only 4 trials, on strings of 500,000 characters, and it takes 50 seconds in debug mode in the broken case, and only 9 seconds in the fixed case. So how can doubling the number of calls to WriteToFlat increase the time by a factor of 4.5?
On Tue, Oct 20, 2009 at 11:08 AM, Anton Muhin <[email protected]> wrote: > Bill, my stance: if one often converts a string, or randomly access > chars, etc., it is a good idea to flatten string. However that > shouldn't be a default behaviour if you only want to serialize a > string into external buffer. > > And I don't think it has n^2 behaviour: you just move/compare tons of > chars several times. > > yours, > anton. > > On Tue, Oct 20, 2009 at 1:04 PM, <[email protected]> wrote: > > LGTM, but is there still a problem with converting cons strings using > > ToCString? > > This method should not be this slow, so avoiding the call to it just > > targets > > the symptoms, not the disease. Does this have n^2 behavior? > > > > http://codereview.chromium.org/294019 > > > -- William Hesse Software Engineer [email protected] Google Denmark ApS Frederiksborggade 20B, 1 sal 1360 København K Denmark CVR nr. 28 86 69 84 If you received this communication by mistake, please don't forward it to anyone else (it may contain confidential or privileged information), please erase all copies of it, including all attachments, and please let the sender know it went to the wrong person. Thanks. --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
