Closed Bug 607686 Opened 15 years ago Closed 14 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

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: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.