Use a PIC-like technique to do these inline. charCodeAt gets called 203K times and charAt 24K times by SunSpider. JM wanted SS win: 17 ms

This depends on bug 578912. Discussion of the PIC-like technique should occur there.

This builds on the patch for bug 578912. When generating a call to a fast native, it checks if the function is charCodeAt and generates a fast path for that, which in the common case avoids the function call and some stack I/O. The code is kind of hacked-together right now, and ideally would be made general enough that we can easily fast-path specific functions. This saves 5% to 10% of string-base64, which is about .5 to 1 milliseconds on my machine (where sunspider takes about 400ms to run). Based on numbers from bug 578912, comment 8, we'd be able to save more by fast-pathing other fast natives, but we probably won't get more than 3 or 4 milliseconds total with this approach, so there's a good chance it isn't worth the added complexity.

Updated patch + added fast paths for charAt, fromCharCode. This patch is very hackish but it works and passes jit-tests. For a micro-benchmark I get these times: charAt (charCodeAt is similar): - JM before: 200 ms - JM after: 122 ms - v8: 89 ms - TM: 68 ms fromCharCode: - JM before: 183 ms - JM after: 101 ms - v8: 63 ms - TM: 84 ms SS and V8 don't improve much, base64 becomes 1.6 ms faster (JM-only, from 10.8 to 9.2). It does help Peacekeeper's SHA1 benchmark which becomes 2.5% faster. I think this can get a bit faster by moving some of the common call instructions out of the slow path; time spent in the actual string path is less than 25%.

(In reply to comment #3) > out of the slow path "fast path", of course...

We will inline these at compile-time using type inference (bug 621961), will be faster and easier than using IC's.