Bug 11576 – .25% performance regression on JS iBench due to JSImmediate changes

• Component: JavaScriptCore
• Status: CLOSED INVALID

[Geoffrey Garen]

Platform compatibility changes to JSImmediate.h between r17372 and r17740 caused a .25% performance regression on JS iBench. I ran the test twice.

I suspect either that something is no longer being inlined, or that something that used to be a compile-time constant is now a run-time lookup.

[Alexey Proskuryakov]

Is this on Intel or PowerPC? I have checked PowerPC disassembly, and JSImmediate is still fully inlined (the intermediate helpers are simply not present in the object code:

otool -tvV JavaScriptCore | grep JSImmediate | c++filt

I have also checked several call spots to verify that the constants haven't magically moved to data segment or anything.

> changes to JSImmediate.h between r17372 and r17740

Does reverting this single file to r17372 fix the regression?

I have tried reverting this file and comparing full JavaScriptCore disassemblies, but that proved difficult - gcc has slightly moved a lot of code and data for whatever reason. However, I did spend some time comparing them, and found no smoking gun.

[Geoffrey Garen]

Intel. MacBook Pro. 

Yes, reverting just JSImmediate.h fixes the regression. That's how I ran the test.

.25% is a small change, but it's slightly greater than JS iBench's margin of error (which is about .15%-.20%).

[Alexey Proskuryakov]

Hmm, Intel disassembly also looks OK...

The biggest change I see is that many large switches (such as those in callAsFunction methods) now have their cases ordered differently, for no apparent reason.

[Mark Rowe (bdash)]

<rdar://problem/4960249>

[Oliver Hunt]

Closed in radar