1271947 - Decryption process takes a long time, decrypting with pbkdf2 algorithm.

Status: RESOLVED WONTFIX

(Core :: XPConnect, defect)

Description

[Slava Mukha]

Attachment: This is a prototype extension where you can reproduce the problem.

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Steps to reproduce:

We use pbkdf2.js library in our extension. This lib you can find here - https://searchcode.com/codesearch/view/73043715/.

We decrypt some data using this library.


Actual results:

After Firefox updated from 44 to 45 version, we've got a problem that decryption process takes too long time (about 10 seconds) but under Firefox 44 and below it was about 1 second.


Expected results:

In Firefox 45 and above decryption process should take about 1 second.

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Test times (ms): 8122, 7467, 7250, 7296

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0
Test times (ms): 1041, 1093, 1126, 1044

It'd be easier for testing to set up a static html page that runs the test a few times.

Comment 2

[Slava Mukha]

When we prepared the html page, we found out that it worked just fine - decryption process took about 1 second. So we think that the problem is definitelly under the extension.
I'll attach the html page we've prepared asap. But not shure that it will be helpful..

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

Oh, that's interesting. It'd still be good to have the page for comparison. This could be related to add-on script compartments.

Comment 4

[Slava Mukha]

Attachment: Simple html page with some scripts that runs decryption process.

This is the html page that has a js script which runs the decryption process.
But in my opinion it might be useless, because in this case the problem of is not reproduced. It is only reprodused under the extension.

By the way.. We're developing new addon SDK extension (it's gonna be replaced with an old one in a few month) and we do the same decryption but on the Panel side and there is everything ok there - decyption process takes about 1 sec.

Comment 5

[Jan de Mooij [:jandem]]

Alice, would you be interested in bisecting this? If not, that's totally fine and I'll do it myself :)

Comment 6

[Alice0775 White]

Regression window w/ attachment 8751235 [details] :
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1e25cd3e8219&tochange=35dcddea2c7a

Regressed by: Bug 1030420


And, indeed, Setting dom.compartment_per_addon = false fixes the performance problem.

Comment 7

[Alice0775 White]

Regression window w/ attachment 8751235 [details] and force dom.compartment_per_addon = true:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=efc771d4648c&tochange=53bfc7d49029

Regressed by:  Bug 990729

Comment 8

[Bobby Holley (:bholley)]

So, compartment-per-addon hoists XPCOM addon code into a separate compartment that interacts with the original global over a special wrapper so that we can inject compatibility shims as-needed to support multiprocess Firefox. If you're doing something with the global object in a tight loop, the overhead of these wrappers is likely what's slowing things down.

The "correct" solution is to rewrite the extension as WebExtension, where everything will Just Work. Depending on what the addon does, there might be workarounds. For example, if the addon is using window.crypto, you can create an XPConnect Sandbox global with access to 'crypto' and operate on it directly from there.

See https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.Sandbox , specifically the 'wantGlobalProperties' section. The documentation doesn't mention 'crypto' as an option, but it was recently added: http://searchfox.org/mozilla-central/rev/e07e80ac43fb06913305890fed3aa9273e7533f0/js/xpconnect/src/Sandbox.cpp#914

Comment 9

[Jan de Mooij [:jandem]]

(In reply to Bobby Holley (busy) from comment #8)
> If you're doing something with the global object in a tight loop,
> the overhead of these wrappers is likely what's slowing things down.

I can confirm we spend most time under NameIC::update -> ... -> writeToProto_getProperty

Comment 10

[Bobby Holley (:bholley)]

Yes, writeToProto_getProperty is the interposition stuff we apply to legacy XUL addons.

Comment 11

[Andrew Overholt [:overholt]]

So is there anything to do here?

Comment 12

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

The e10s shims have a good amount of overhead. That can be reduced by avoiding global variables and marking the add-on multiprocess compatible. But the real solution here is to use WebExtensions.