Threadsafe builds take about a 6-7% Kraken hit and 8-9% SunSpider hit over non-threadsafe builds. This is skewing AWFY results (which now uses threadsafe builds) and may be affecting the browser as well.

Are you sure it's all source compression. IIRC, threadsafe builds were slower (thought perhaps not that much) before, too.

Yeah, Bill said the majority was from source compression.

I saw big regressions in a few Kraken benchmarks that went away when I turned off the source compression thread. However, it only happened on one of my machines, which is weird.

Are there plans to address these regressions? Owner? ETA?

I tried last month to reproduce this on my machine with no luck --- similar scores, or a tiny regression from switching to a threadsafe build. It'd be nice to know more about the sort of configurations that see significant differences between non-TS shell builds, TS shell builds and the browser itself.

Nicolas suggested on dev-tech-js-engine-internals: > One way to fix this would be to disable source compression on sources coming from load > (shell benchmark) and iframes (browser benchmark). If there's no bug filed on that idea, perhaps this bug will do. It's all about "regression" as measured by such one-shot-load benchmarks. /be

Someone who see's this regression (I don't) should try the patch from bug 821040. It might make a difference.

A similar issue is investigated in Bug 836515 (gaia) where the problems comes from the fact that the source compression is doing a blocking wait until the end of the compression of the previous sources. So optimizations for Bug 836515 should be visible on sunspider.

Bug 836515 seems to have indeed helped.

Could somebody who experiences this retest? I think AWFY is back to pre-threadsafe build numbers.