On Tue, Oct 20, 2009 at 3:56 PM, William Hesse <[email protected]> wrote: > I guess since I am the one interested, I'll look deeper into it when I have > the time. I guess the bug can be closed. Are we sure that the 9 second > time we have now is comparable to the time they had before the slowdown?
I am looking into it in a background mode. Actually using stringinputbeffer the way ToWideCString uses it is incredibly slow: if I change this loop into WriteToFlat time goes from 33 secs to .5 secs (sic!). I suspect that decode char might be very expensive. Don't think there is any n^2 lurking around, but only investigation will show. And yes, I guess that is the number: I compared against the version which flattens string first. yours, anton. > > On Tue, Oct 20, 2009 at 12:35 PM, Anton Muhin <[email protected]> wrote: >> >> On Tue, Oct 20, 2009 at 2:17 PM, William Hesse <[email protected]> >> wrote: >> > It looks to me like WriteToFlat is called once, to write to the external >> > resource, in the fixed case, and that >> > it 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? >> >> Bill, do you want me to investigate that further? I definitely would >> if you like, just not sure this problem of top priority. >> >> My thoughts. memcmp is cheap, but is not free. And I'd expect >> writing the string out to be somewhat more expensive than >> WriteToString---additional checks, etc. That's, for sure, just >> speculations, so if you think I should look deeper, I'd do. >> >> yours, >> anton. >> >> > >> > 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. >> > >> > > > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
