2009/10/21 Anton Muhin <[email protected]>: > They already have. Good point. I don't know how I missed that.
> So looks like the plan is to submit this CL and forget about it? Yes! > 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 -~----------~----~----~----~------~----~------~--~---
