930540 - Performance issues with comparing numbers and strings

Status: NEW

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Till Schneidereit [:till]]

Attachment: 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.

Comment 1

[Nicolas B. Pierron [:nbp]]

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.

Comment 2

[Till Schneidereit [:till]]

Ah, nice. Thanks for the heads up.

Comment 3

[Lars T Hansen [:lth]]

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.

Comment 4

[André Bargull [:anba]]

bug 1467907 improved the second version, but it's still slower than the third one. bug 813836 made the first version as fast as the fourth one.