On 6/22/17 4:43 AM, Henri Sivonen wrote:
The length of the string is always well over 100, so that already
means that a string cache isn't interfering with the test, right?
The way the string cache works is that it will reuse an existing
JSString* in two situations:
1) The nsStringBuffer* is the same exact pointer as the cached thing.
2) The nsStringBuffer* is different, but length < 100 and the chars
match the cached thing.
In your case, situation 2 is not applying; presumably situation 1 is not
either, so you create a new JSString. I think Jan is suggesting that
you could make situation 2 apply by raising that "100" limit. Whether
the resulting compare is faster than allocating JSString and GC is not
obvious, of course.
Jan said "We create external strings (a JS string referencing a DOM
string buffer) for the strings returned from DOM to JS", so that means
Gecko does roughly the same in this case, right?
With a bunch more overhead (atomic refcounts, function calls, etc), but yes.
Could it be that JSC
realizes that nothing holds onto the string and derefs it right away
without having to wait for an actual GC?
Possible. I haven't looked at their code in a while.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
