11576 2006-11-11 21:32:07 -0800 .25% performance regression on JS iBench due to JSImmediate changes 2007-07-13 21:40:33 -0700 1 1 1 Unclassified WebKit JavaScriptCore 420+ Mac OS X 10.4 CLOSED INVALID InRadar P1 Normal --- 1 ggaren webkit-unassigned ap dgibson77 mjs oldest_to_newest 45972 0 ggaren 2006-11-11 21:32:07 -0800 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. 45987 1 ap 2006-11-12 01:46:49 -0800 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. 45923 2 ggaren 2006-11-12 16:15:06 -0800 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%). 45914 3 ap 2006-11-12 22:08:16 -0800 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. 31254 4 mrowe 2007-01-28 19:01:41 -0800 <rdar://problem/4960249> 4841 5 oliver 2007-07-13 21:40:17 -0700 Closed in radar