Open Bug 1525260 Opened 3 years ago Updated 3 months ago

RSA Encrypt is VERY SLOW in firefox

Categories

(Core :: JavaScript Engine: JIT, defect, P3)

x86_64
Linux
defect

Tracking

()

Performance P3

People

(Reporter: linuxcbon, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: perf, perf:responsiveness)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Run http://dromaeo.com/?v8
Same OS, same Hardware and compare 2 browsers results :
Firefox 65.0 (64 bits)
Seamonkey 2.49.4 (64 bits)

Actual results:

Firefox extremely slow for RSA Encrypt

Firefox 65.0 (64 bits)
RSA Encrypt: 1909.05runs/s ±5.15%

Seamonkey 2.49.4 (64 bits)
RSA Encrypt: 2408.20runs/s ±11.74%

Expected results:

Firefox should be much faster in RSA Encrypt, something is wrong here !

Severity: normal → major
Component: Untriaged → General
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Firefox:general is in general wrong and untriaged is the right component for new reports with an unknown product/component.

Component: General → JavaScript Engine
Product: Firefox → Core
Component: JavaScript Engine → JavaScript Engine: JIT

For information RSA Encryption/Decryption from Dromeao is supposed to be the same as Octane Crypto. However, I do not see any recent regressions on Octane-crypto from https://arewefastyet.com/linux64/octane?numDays=345

Maybe this is a GC scheduling specific to Firefox, or just a noise issue.

Priority: -- → P2
Whiteboard: [qf]

Thanks for the report. Note that SeaMonkey 2.49.4 is based on Firefox 52 codebase; it seems conceivable that something regressed between that version and current Firefox 65.

If someone who can reproduce the perf-difference here could also test Firefox 52 ESR, that'd be a useful data point to have. I think that's available here: https://ftp.mozilla.org/pub/firefox/releases/52.0esr/

Whiteboard: [qf] → [qf:p3:responsiveness]

Firefox 60.5.2esr (64-bit)
RSA Encrypt: 1980.40runs/s ±7.14%

still slow in comparison to Seamonkey 2.49.4
but firefox 65.0 is even slower than firefox 60.5.2

So here are the results :
Seamonkey 2.49.4 2408.20runs/s ±11.74%
Firefox 60.5.2esr 1980.40runs/s ±7.14%
Firefox 65.0 1909.05runs/s ±5.15%
Any idea ?

Flags: needinfo?(sdetar)
Keywords: perf

linuxcbon: Thank you for reporting this issue. Our highest priority at the moment is focusing on page-load performance. This bug is on our priority list to return too when we get back at optimizing for steady performance.

One way to help make this a higher priority would be if you or someone could better bisect the source of this regression, if this ended up being a small issue with a simple fix, it would be easier to make this a higher priority.

Flags: needinfo?(sdetar)

For information, the code can be found here http://dromaeo.com/tests/v8-crypto.html
It's a complex code, so the slowness could come from arrays or strings or other functions.

I opened 2 bugs concerning arrays and strings slowness, to check more precisely each topic.
https://bugzilla.mozilla.org/show_bug.cgi?id=1536125 Some strings functions are slow (Concat , toLowerCase, toUpperCase, comparing)
https://bugzilla.mozilla.org/show_bug.cgi?id=1536122 Some Array functions are slow ([], splice, shift)

Depends on: 1536125, 1536122

Hello! I have tried to reproduce the issue with the STR provided in the description but I could not reproduce it with firefox 96.0a1(2021-11-08) on Ubuntu 20.04.

Could you please provide some more detailed steps on how to reproduce/use the code provided in the description in order for the QA to further investigate this issue?

Thank you!

Flags: needinfo?(linuxcbon)

The STR here are essentially "run the benchmark, look at the results".

Unfortunately the URL from comment 0 doesn't work anymore; http://dromaeo.com/?v8 redirects to https://github.com/jeresig/dromaeo which is a view of the benchmark's now-archived code.

I did find one still-available "live" instance of the benchmark, though, here:
https://dromaeo.uplinklabs.net/?v8

So the updated STR are just to load that^ page, click "run", and look at the results. I did that and noticed that our results have gotten a good bit worse in the time since this bug went quiet; it looks like bug 1666417 ("Warp") caused a regression on this RSA microbenchmark. In Nightly 2020-09-23 (the first Nightly to ship with Warp): if I run with Warp manually-disabled, I get 1051.40runs/s for RSA Encryption/Decryption, vs. 439.32runs/s with Warp enabled. Current Nightly is slightly better but still in the same ballpark (521.83runs/s).

For comparison, Chrome 97 dev gets 1437.64runs/s; so there's definitely room to be better here.

Per bug 1667797 comment 2, it looks like we were aware that Warp incurred some substantial regressions in Dromaeo's microbenchmarks, and we're prioritizing other real-world benchmarks which got a boost from Warp.

So, given that bug 1666417 was WONTFIX'ed, I suspect/assume the Dromaeo "RSA" microbenchmark regression from Warp is a known/expected outcome, and we're probably not especially focused on closing the gap on this particular benchmark at this point (which is what this bug was tracking).

jandem, should we close this bug out at this point?

Flags: needinfo?(linuxcbon) → needinfo?(jdemooij)

(In reply to Daniel Holbert [:dholbert] from comment #9)

jandem, should we close this bug out at this point?

Either leaving open or closing works for me... This isn't high priority for us at the moment because this benchmark isn't very representative of code on actual websites, but it would still be nice to improve this over time.

Blocks: sm-jits
Flags: needinfo?(jdemooij)
Severity: major → S4
Priority: P2 → P3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 65 Branch → unspecified
Performance: --- → P3
Whiteboard: [qf:p3:responsiveness]
You need to log in before you can comment on or make changes to this bug.