Hermes: Another possible performance issue, with non-integer numeric property names

[YaoHouyou]

When running the testcases below, hermes takes more than ten times execution time of other engines. Maybe, it is an issue of hermes.

Version:

3826084

Testcase:

var NISLFuzzingFunc = function(array, from, to) {
    var counter = 0;
    while (to < from) {
        if (array[to] === array[to]) {
            to++;
        }
    }
};
var NISLParameter0 = [true];
var NISLParameter1 = 4077282;
var NISLParameter2 = 1.541384329975526;
NISLFuzzingFunc(NISLParameter0, NISLParameter1, NISLParameter2);

Command:

build_release/bin/hermes -w testcase.js

Execution time:

V8: 4098 ms
spiderMonkey: 3355 ms
chakra: 2439 ms
javascriptCore: 3315 ms
hermes: 55334 ms

[tmikov]

Thank you for reporting this. It is caused by using a non-integer array index. Such a pattern is unlikely to happen in production code, so it is not clear that it needs to be optimized, but we will investigate to see why the perf gap is so large. Perhaps it is an indication of something else being slower than it needs to.

[tmikov]

Digging into this turned out to be useful: 62a0ab047913e0aa27cfddf7066dcc7bf2edd7c2 removes a bottleneck in dtoa and improves the performance by a factor of 2. I suspect the rest of the difference reflects an inherent perf limitation of dtoa.

I still can't think of a realistic case for code like this, but I will keep this issue open in case there are further wins to be had in dtoa.