Brian's observations: Hi, I've gone through the various overheads for the Array microbenchmark from the last email to see what can be done (this also applies to the similar overheads in the other microbenchmarks). For this code: function test() { for (var i = 0; i < 1000000; i++) { var a = new Array(4); for (var j = 0; j < 4; j++) a[j] = 0; } } Vs. always using the same array (hoisting 'var a = ...' out of the loop), JM's overhead with the last patch and no slow path when setting a hole (this can be fixed, without using type inference) is 355ms, vs. 81ms for JSC (4.4x). Using timers to profile where that overhead is, I get these numbers (these add to slightly more than 355ms, the timers aren't exact). - 15ms: JaegerShot Probably not out of line with JSC. - 43ms: SetElem These are the slow paths taken when resizing the arrays. Arrays are created empty, then a slow path is hit the first time an element is assigned to. Giving arrays some initial space removes this overhead, at the downside of wasting space/time for arrays which never have elements --- how common is this? - 66ms: Array These are the Array constructor calls, modulo the object allocations themselves. Constant overhead, but could be optimized (several inlinable calls). - 81ms: NewFinalizableGCThing This is mostly (65ms) in calls to MakeNewArenaFreeList, which walks an entire 4KB page to make a freelist out of it. This could go away by using a frontier pointer instead for never-used memory? How often are allocations done out of previously used memory for browser vs. shell? - 171ms: resizeDenseArrayElements This is about 80ms in calls to realloc, 90ms in filling the result with holes. realloc is slow vs. GC allocations in JSC; assuming the NewFinalizableGCThing overhead is fixed, could (small or all) arrays have their data on the GC heap? The time for filling with holes could be removed but would need more information in the fslots and different tests; in any case this may change by using the GC heap for the array buffers. Brian

Current js shell numbers for the testcase in comment #0: Interp: 723.092 ms -j: 712.236 ms -m: 117.500 ms -m -n: 77.205 ms So JM+TI is roughly 10x faster than interp and a lot faster than comment #0. I don't have a d8 or JSC shell handy to compare against, though.