To make external strings really fast, we really want to be able to take a char* and not have the JS engine do anything (like expand each char to fit in a jschar). Brendan indicated that this should be doable, but that we should talk to Luke. I'm filing this bug to track all this. :)
Hmm. Does V8 actually do that?
It's unclear at this time, although they certainly have an API to make an external string from ascii data. For the Node guys, the expanding and then shrinking back down when going from a syscall to JS and then back to a syscall is really expensive. I suspect we have cases like this too where that'd help us in perf, although the node guys are likely using larger strings.
Here's an idea: Analogous to JSRope representing a delayed concatenation, we could have a JSAsciiString which represents a delayed inflation to jschar by storing the char array. We'd want to add a new JSAPI function that was able to return this char array directly when given an JSAsciiStrings. This would only win if most JSAsciiStrings never have there jschars accessed in the JS engine. Another possibility is that we lose by repeatedly asking for the char array of a string (which will inflate each time). In this case, it would make sense to use JSFixedString's free word to cache the char array. Merging these two ideas, we could have JSAsciiString transition to JSFixedString if it gets inflated thereby remembering its char array. Shawn: do you know if the ASCII strings that get created by Node have their chars access from JS or are they primarily accessed via JSAPI to pull the ASCII chars out again?
I poked the Node.js guys about this, but haven't gotten a response back. I haven't forgotten about this bug! :D
You need to log in before you can comment on or make changes to this bug.