Chrome is 5.6x faster at crypto.subtle.digest




DOM: Security
3 years ago
4 months ago


(Reporter: err, Unassigned)


(Depends on: 1 bug)

35 Branch
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [domsecurity-backlog2])


(1 attachment)



3 years ago
Created attachment 8491191 [details]
sha benchmark.htm

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 -
(nightly with E10S labeled as "Firefox 35.00.10")
Component: JavaScript Engine: JIT → DOM: Security
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.
Depends on: 1001691
Ever confirmed: true
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.

Comment 3

3 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.
Right, there's really no point measuring this until bug 1001691 is fixed.
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.
Component: DOM: Security → Security
I did some re-profiling and a lot of the time is actually spent in the promise code.  Should remeasure once bug 911216 lands.
Depends on: 911216
Component: Security → DOM: Security
Priority: -- → P3
Whiteboard: [domsecurity-backlog2]
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.
Depends on: 1280819
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.
Last Resolved: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.