Closed Bug 1271947 Opened 8 years ago Closed 8 years ago

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


(Core :: XPConnect, defect)

45 Branch
Not set





(Reporter: viacheslav.mukha, Unassigned)



(Keywords: perf, regression)


(2 files)

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 -

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.
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.
Ever confirmed: true
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..
Oh, that's interesting. It'd still be good to have the page for comparison. This could be related to add-on script compartments.
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.
Alice, would you be interested in bisecting this? If not, that's totally fine and I'll do it myself :)
Flags: needinfo?(jdemooij)
Regression window w/ attachment 8751235 [details] :

Regressed by: Bug 1030420

And, indeed, Setting dom.compartment_per_addon = false fixes the performance problem.
Component: JavaScript Engine → XPConnect
Flags: needinfo?(bobbyholley)
Flags: needinfo?(wmccloskey)
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 , specifically the 'wantGlobalProperties' section. The documentation doesn't mention 'crypto' as an option, but it was recently added:
Flags: needinfo?(bobbyholley)
Blocks: 1272763
(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
Flags: needinfo?(jdemooij)
Yes, writeToProto_getProperty is the interposition stuff we apply to legacy XUL addons.
So is there anything to do here?
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.
Closed: 8 years ago
Flags: needinfo?(wmccloskey)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.