Closed Bug 619343 Opened 11 years ago Closed 11 years ago
Inference: reading holes is slower with type inference
I noticed this when profiling Kraken's ai-astar. For the attached test case: - JM: 87 ms - JM (inference): 107 ms When I change "x = 0" to "x = 1" (eg. reading an int): - JM: 17 ms - JM (inference): 13 ms <bhackett> two ways to fix <bhackett> 1. do what we do for 3d-raytrace, if testing a property like if (x[i]) assume the result could be undefined, and handle that in the compiler <bhackett> 2. only add undefined to reads of arrays where undefined has actually been observed ... <bhackett> we should do both 1. and 2. above <bhackett> the cost of recompiling more often is less than the cost of less precision
11 years ago
I was wrong on this, we actually were marking undefined as a possible result of 'if (a[x])' so did not recompile here. The problem is that we slow path every hole read out of the array, and that slow path now has to check that the inference knows about the undefined value every time it pushes undefined. This patch fixes this by fast-pathing hole reads out of an array when (a) the pushed value is known to contain undefined, and (b) Array.prototype and Object.prototype do not have indexed properties. http://hg.mozilla.org/projects/jaegermonkey/rev/6e0795e82953 This doesn't make much difference on ai-astar. The problem there is that having more type information ends up generating much worse code on object equality; I filed bug 619592 for that issue.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
FWIW, for the attached microbenchmark: - JM: 87 ms - JM (inference): 14 ms (was 107 ms) Nice!
You need to log in before you can comment on or make changes to this bug.