Closed Bug 607686 Opened 13 years ago Closed 12 years ago

Consider whether integer-only loops should be traced

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bzbarsky, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [jsperf])

It's not clear whether we want to do this, but consider this testcase:

var t1;

t1 = new Date;
for (var b = 0; b < 1e6; b++) {
    var i = 1000;
    var rest = i % 3;
    var div = parseInt(i / 3);
}
print(new Date - t1);

t1 = new Date
for (var b = 0; b < 1e6; b++) {
    var i = 1000;
    var rest = i % 3;
    var div = (i - rest) / 3;
}
print(new Date - t1);

The numbers I see are:

-j: 11, 3
-m: 33, 22
-m -j -p: 11 22

What happens is that both loops have 17 total ops.  The first loop has one call and one int op, and 25 > 17, so we trace.  The second loop has two int ops and nothing else; 10 < 17, so we don't trace.

Maybe we should consider more aggressively tracing int-only code...
Whiteboard: [jsperf]
From time to time, i see such kind of micro benchmarks:
for (var i = 0; i < 50000; i++)
  a += i;

We should really trace this one.
Keywords: perf
For the testcase in comment 0:
Interp: 520, 472
TM: 501, 457
JM: 76, 40
JM+TI: 55, 27
d8: 66, 37

For the testcase in comment 1 (running the loop 1000000 times):
Interp: 227
TM: 223
JM: 17
JM+TI: 6
d8: 27

Looks like JM+TI has this case solved.
Blocks: 467263
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.