If we had such a beastie, we could handle repeated attempts to JS-wrap the same stringbuffer by just lookup and returning the JSExternalString. The finalizer we use for JSExternalString could remove from the hashtable as needed.

This would be similar to JSStringCache used in JSDOMBinding.h Which was added in https://bugs.webkit.org/show_bug.cgi?id=33768

I loaded gmail, zimbra, New York Times, a few other websites I can't recall, Google Reader. There are about 65000 entries. Of those, about 500 are during browser startup.

Assuming I didn't screw anything up, this should measure hit and miss rates for a one-slot cache and a hashtable. And those are: Slot hits: 12155 misses: 20369 Cache hits: 21845 misses: 10679 So even the one-slot cache ends up hitting more than 37% of the time. I vote we just do that. ;)

Comment on attachment 642183 [details] [diff] [review] This shaves another 15ns off a typical getAttribute call. There's still more gunk in the string-wrapping code (e.g. several levels of function calls), unfortunately. Review of attachment 642183 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me, sorry for the delay.

Comment on attachment 642183 [details] [diff] [review] This shaves another 15ns off a typical getAttribute call. There's still more gunk in the string-wrapping code (e.g. several levels of function calls), unfortunately. Review of attachment 642183 [details] [diff] [review]: ----------------------------------------------------------------- Don't forget to replace NULL with nullptr.