err Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35) Gecko/20100101 Firefox/35.00.10
Build ID: 20140917030202

Steps to reproduce:

I would like to use window.crypto.subtle.digest() as a seedable random to generate lot of values, but in current Firefox Nightly it makes a noticeable delay.


Actual results:

Turns out that Chrome calculates SHA digest about 5.6 times faster on my desktop (Win7 x64, Intel E8400 CPU).

See the attached benchmark or this jsperf - http://jsperf.com/sha-digest
(nightly with E10S labeled as "Firefox 35.00.10")

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 10 years ago

Fwiw, on Mac I only see about a 2x difference.

Looking at a profile, at least 25% of the the time is the NS_NewThread gunk caused by every single hash() call starting a new thread.  I _think_ bug 1001691 is supposed to cover that?

Until that's fixed, I'm not sure there's a point in measuring here, since the many random threads also mean lots of time waiting, etc.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 10 years ago

Oh, and another 25% is PR_JoinThread.  And there's my 2x difference!

On Windows, threads are more expensive, as I recall, which might explain why it's a 5.6x difference there.

	Guilherme Lima
	Comment 3 • 10 years ago

I see a huge difference (Win 7)

Chrome 41 takes 170ms
Nightly takes 6200ms (e10s on) and 7200ms (e10s off)
Firefox 36.0.1 takes 11700ms
The rapportmgmtservice.exe from IBM Trusteer used by Banco do Brasil makes Firefox to take 65000ms.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 10 years ago

Right, there's really no point measuring this until bug 1001691 is fixed.

	Tim Taubert [:ttaubert] (inactive)
	Comment 5 • 9 years ago

With the current patches from bug 1001691 I see:

Fx Nightly: 5,3k computations
Fx Nightly with patches: 13,2k computations
Chrome Canary: 20,9k computations

Still not where we'd like to be but roughly 2.5 times faster. Can look into it more after the patches landed.

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 9 years ago

I did some re-profiling and a lot of the time is actually spent in the promise code.  Should remeasure once bug 911216 lands.

	Till Schneidereit [:till]
	Comment 7 • 8 years ago

I see current Nightly taking ~350ms here, vs ~200ms for Chrome. However, if I disable async stacks, Nightly takes ~230ms. Blocking on bug 1280819 because of that.

The jsperf benchmark isn't available, so I can't comment on that.

	Till Schneidereit [:till]
	Comment 8 • 7 years ago

We're now faster on both the jsperf test and the attached benchmark: 28k ops/sec vs 21k ops/sec on the former and 135ms vs ~210ms on the latter.