1.81 KB, text/plain
Created attachment 821688 [details] Benchmark showing performance if various isNumeric implementations The attached benchmark compares various implementations of a test for whether a string is numeric. Issues uncovered here: - comparing single characters is slow, as demonstrated in the first isNumeric - parseInt is comparatively slow - `parseInt(val) + '' == val` is ~35% faster than `parseInt(val == val` (yes, there are semantic differences. The RHS `val` being coerced to number might explain the perf difference, but it doesn't seem likely.) Depending on how hard it is to inline parseInt, we could look into self-hosting at least the base10 version of it, with a native slow path.
There is already some room reserved in the String representation to make Int-to-String conversion faster, by just storing an int until the string is flattened. See Bug 654190.
Ah, nice. Thanks for the heads up.
Still with us, this is on my MacBook Pro: Took: 1600 Took: 463 Took: 150 Took: 50 --ion-offthread-compile=off does not materially change anything (everything slows down by a few ms, that's all). The difference between the second and third is unfortunate, as Till already pointed out. The difference between the first and the fourth is worrisome, since these are the same program except one using string indexing and one using charCodeAt. (Cleaning up the first program to cache the value like the fourth does not make much difference.) Adding a fifth program that uses x.charAt instead of x[n] has the same speed.