if (clasp == &js_FunctionClass && !objectSize) { obj = (JSObject*) js_NewGCFunction(cx); #ifdef DEBUG if (obj) { memset((uint8 *) obj + sizeof(JSObject), JS_FREE_PATTERN, sizeof(JSFunction) - sizeof(JSObject)); } #endif } else { JS_ASSERT(!objectSize || objectSize == sizeof(JSObject)); obj = (clasp == &js_IteratorClass) ? js_NewGCIter(cx) : js_NewGCObject(cx); } This should be a parameterized template that gets instantiated and then properly inlined. If we do this right the right path gets folded into the call based on a constant clasp == &ActualClass comparison.

Igor, interested or shall I?

Patch in a sec. For the following test case this is an 8% speedup: var t = Date.now(); for (var i = 0; i < 500000; ++i) ({}); print(Date.now() - t); Sunspider numbers next.

Looks like unpack-code allocates a lot of objects. The rest doesn't change significantly. unpack-code: 1.064x as fast 84.5ms +/- 0.2% 79.4ms +/- 0.2% significant

(In reply to comment #0) > This should be a parameterized template that gets instantiated and then > properly inlined. If we do this right the right path gets folded into the call > based on a constant clasp == &ActualClass comparison. The comparison clasp == &ActualClass cannot be constant since the compiler does not know the address of the ActualClass. On the other hand if we do the dispatch over the finalization kind then the compiler can optimize. I guess we need another patch about that.