821040 - Source compression introduces large regression in threadsafe builds

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

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.

Comment 1

[:Benjamin Peterson]

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

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Yeah, Bill said the majority was from source compression.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 4

[Paul Wright]

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

Comment 5

[Brian Hackett [Laid off!]]

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.

Comment 6

[Brendan Eich [:brendan]]

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

Comment 7

[:Benjamin Peterson]

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

Comment 8

[Nicolas B. Pierron [:nbp]]

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.

Comment 9

[:Benjamin Peterson]

Bug 836515 seems to have indeed helped.

Comment 10

[:Benjamin Peterson]

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