Closed Bug 916464 Opened 12 years ago Closed 11 years ago

Performance of OpenPGP.js in add-on module

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla35

People

(Reporter: thomas, Assigned: jandem)

References

Details

Attachments

(2 files)

pgp_decrypt_test.zip
127.76 KB, application/octet-stream
Details
openpgp_page_worker.zip
155.99 KB, application/octet-stream
Details
Attached file pgp_decrypt_test.zip —
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 2013080200 Steps to reproduce: Running OpenPGP.js as an add-on module shows poor performance. Problems on Firefox were first reported here: https://github.com/openpgpjs/openpgpjs/issues/83 But in this case OpenPGP.js was loaded as a normal script and the issue was resolved by deactivating Firebug. In my case I want to use OpenPGP.js in an add-on based on the Add-on SDK and therefore OpenPGP.js runs as a module. Actual results: In the attached test case we see a normal PGP decryption process: the key is unlocked and a message is decrypted. Following test result (on Core2 2.4GHz): info: pgp_decrypt_test: OpenPGP.js decrypt test info: pgp_decrypt_test: Decrypt secret part of private key... info: pgp_decrypt_test: Time elapsed (s): 34.975 info: pgp_decrypt_test: Decrypt message... info: pgp_decrypt_test: Time elapsed (s): 5.603 info: pgp_decrypt_test: Test finished! Setting the following values to true didn't change the situation: javascript.options.ion.chrome javascript.options.typeinference.chrome javascript.options.methodjit.chrome Time for the whole process: ~40s Expected results: When we execute the same procedure in Chrome (and probably also in Firefox as a normal script) the expected duration is: <2s
Soundsl ike bug 776798, depending on how exactly this code is getting run.
Depends on: 776798
I wrote now a second test case that loads OpenPGP.js and does the decryption in a page-worker (see attachment). Test results as follows: info: openpgp_page_worker: OpenPGP.js page worker test info: openpgp_page_worker: Decrypt secret part of private key... info: openpgp_page_worker: Time elapsed (s): 0.668 info: openpgp_page_worker: Decrypt message... info: openpgp_page_worker: Time elapsed (s): 0.088 info: openpgp_page_worker: Test finished! Quite nice. But the question is how to access the OpenPGP.js object inside the page-worker from the add-on? AFAIK this is only possible with the messaging API, therefore I would need to write an adapter that translates all calls to the OpenPGP.js API to send/receives via a port. Is there possibly an easier solution?
Depends on: 880330
Sorry for forgetting about this bug til now. :-( At least someone looked at it before this comment... There's not really a good solution for converting existing synchronous-call code to a message-passing interface, that I'm aware of. If there were, we'd be using it to make desktop Firefox have out-of-process tabs more quickly. ;-) I could believe the options-flag location cleanups would help with this. The odds of this being backported to releases are about non-existent, tho, which would mean the usual aurora-beta-release percolation before you could depend upon perf gains.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #5) > There's not really a good solution for converting existing synchronous-call > code to a message-passing interface, that I'm aware of. If there were, we'd > be using it to make desktop Firefox have out-of-process tabs more quickly. > ;-) Yes, I think if a solution is on the horizon that improves the performance of modules based on the Add-on SDK in general, then the message-passing work around is way too much effort. > I could believe the options-flag location cleanups would help with this. > The odds of this being backported to releases are about non-existent, tho, > which would mean the usual aurora-beta-release percolation before you could > depend upon perf gains. I meanwhile tested the options-flag changes with the pgp_decrypt_test.zip test case but so far could not measure any improvements. Added a comment also here: https://bugzilla.mozilla.org/show_bug.cgi?id=885786#c37 Is my assumption correct that https://bugzilla.mozilla.org/show_bug.cgi?id=880330#c53 says that the options-flag changes are included in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ ? I would not mind to wait for Firefox 27. Just want to make sure the improvements then also support the here presented use case :)
Some test updates: pgp_decrypt_test openpgp_page_worker ================ =================== 27.0b4 31.465s 3.96s 0.667s 0.08s 28.0a2 26.239s 2.91s 0.656s 0.08s 29.0a1 25.527s 3.04s 0.785s 0.08s The situation has not changed: code executed in add-on module is still ~30 times slower as compared to normal page script.
It's getting better! Aurora is now 3x faster in the add-on module context as compared to beta channel. pgp_decrypt_test openpgp_page_worker ================ =================== 29.0b5 26.29s 3.16s 0.77s 0.08s 30.0a2 7.47s 0.55s 0.77s 0.08s 31.0a1 7.38s 0.56s 0.84s 0.14s
(In reply to Thomas Oberndörfer from comment #8) > It's getting better! Aurora is now 3x faster in the add-on module context as > compared to beta channel. Bug 939562 :) Your code probably runs in the Baseline JIT now instead of the interpreter, but because the code is not compile-and-go it's not yet Ion-compiled. This shouldn't be too hard to fix. Do you have a simple add-on I can install to verify this?
(In reply to Jan de Mooij [:jandem] from comment #9) > This shouldn't be too hard to fix. Do you have a simple add-on I can install > to verify this? I'm using the two add-ons attached to this bug and "cfx run" for testing. The tests start directly after loading the add-on and write timing info to console. pgp_decrypt_test runs in add-on context while openpgp_page_worker uses a page-worker module for the same workload and is optimized. Let me know if you need any other setup for testing.
Would you mind retesting with the latest Nightly? There have been numerous performance improvements for Worker and chrome contexts.
See Also: → 913182
Some updates: pgp_decrypt_test openpgp_page_worker ================ =================== 31.0b1 7.82s 0.56s 32.0a2 7.68s 0.55s 33.0a1 7.68s 0.58s 0.83s 0.13s 33.0a1 as in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ => No progress since last test
Assignee: general → nobody
Depends on: 1045529
Is this fixed now that bug 1045529 has landed?
Thomas, would you mind testing this with Firefox 34 (Aurora) or 35 (Nightly)? :) Bug 1045529 should have improved this..
Flags: needinfo?(toberndo)
Newest numbers: pgp_decrypt_test ================ 32.0 7.86s 0.56s 34.0a2 5.56s 0.75s 35.0a1 5.58s 0.82s => around 30% better
Flags: needinfo?(toberndo)
Depends on: 1064777
I figured out how to run the attachment. The patch in bug 1064777 improves this a lot: Before: 2.775 / 0.036 After : 0.344 / 0.036 Page worker: 0.313 / 0.041 Fingers crossed bug 1064777 will stick so that we can finally close this :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thomas, can you confirm the latest Nightly fixed this?
Flags: needinfo?(toberndo)
Can confirm this is fixed in latest. Great progress! Thanks. pgp_decrypt_test ================ 35.0a1 5.58s 0.82s latest 0.68s 0.76s
Flags: needinfo?(toberndo)
(In reply to Thomas Oberndörfer from comment #18) > Can confirm this is fixed in latest. Great progress! Thanks. > > pgp_decrypt_test > ================ > 35.0a1 5.58s 0.82s > latest 0.68s 0.76s Nice, thanks!
Assignee: nobody → jdemooij
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: