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.
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 -~----------~----~----~----~------~----~------~--~---
