They already have. So looks like the plan is to submit this CL and forget about it?
yours, anton. On Wed, Oct 21, 2009 at 12:13 PM, Erik Corry <[email protected]> wrote: > 2009/10/20 Erik Corry <[email protected]>: >> 2009/10/20 Anton Muhin <[email protected]>: >>> On Tue, Oct 20, 2009 at 10:22 PM, <[email protected]> wrote: >>>> This LGTM but I still thing we should fix ToCString, probably not by >>>> flattening. >>> >>> Any suggestions? We can write it out flat and start massaging after >>> that like calculating needed size in target encoding, etc. I just >>> think it's a bit involved and apparently doesn't buy as a lot. >>> Probably I should do a simple thing: patch flattenning into to C >>> strings and run it through various perf benchmarks. If it would save >>> us some cycles, it is probably worth effort. Otherwise I don't feel >>> like it's really necessary, but I admit I am just lazy. > > Please ignore my last mail. I now agree with you that it's not worth > spending time on. ToCString and ToWideCString are not used by the API > so they are not that important. They are used only for debugging and > similar. They should perhaps have a comment in objects.h that says > they can be quadratic on unflattened strings. > >> >> I'd like to use WriteToFlat for the cases where we are writing the >> whole string, where nulls are allowed and where we are writing a wide >> string. That should be fairly simple and avoids a nasty case that I >> think we hit otherwise. When an existing string is being externalized >> the alternatives are: >> >> 1) Flatten first >> This will cause a flat string to be allocated. If the string is more >> than 8k then the new string is in large object space, ie it cannot be >> moved by the GC. We then copy the entire thing (again) out to an >> external buffer and then overwrite the start of the JS string with the >> external string object. We have now doubled the space taken up by the >> string, because the large object space buffer can't be freed, but >> cannot be used for anything else (no freelists in large object space). >> 2) Use the StringInputBuffer >> Too slow. >> >> >> -- >> Erik Corry >> > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
