1610820 - CheerpJ generated code runs up to 10x slower on Firefox compared to Chrome

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P3)

Description

[Clemens Eisserer]

Attachment: JavaFiddle.java

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

Steps to reproduce:

CheerpJ is a Java -> JavaScript compiler, much like EmScripten but for Java instead of C++.

1. Pasted the Java-Benchmark attached into CheerpJ's Fiddle tool
2. Clicked the "run"-Button

Actual results:

Firefox takes about 10x as long to complete a benchmark run compared to Chrome.

Native Java: 40ms
Chrome: 310ms
Firefox: 3200ms

Expected results:

Firefox should be somewhere in the same ballpark as Chrome, not 10x slower.

Comment 1

[Seba S.]

Hi, Clemens!

Thanks for your contribution!

I don´t have the technical knowledge in order to reproduce this but I'm adding product and component to this issue to keep on track.

Please let us know if this issue is reproduced in the latest Nightly edition. You can download it from here: https://nightly.mozilla.org/

If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
support.mozilla.orgsupport.mozilla.org

Once you have all this information, please let us know so we can continue investigating.

Regards,

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

So, on my machine the results are worse in the sense that I get a slow script dialog in nightly.

The fiddle website is here: https://javafiddle.leaningtech.com/

A profile is here: https://perfht.ml/2RChKU0

I suspect this benchmark is stressing the GC, as I see in the profile we're effectively constantly doing a GCMinor with reason OUT_OF_NURSERY.

Comment 3

[Clemens Eisserer]

Matthew:
I just had a look at how the generated code behaves with chrome and there I can't see excessive heap allocations.
Maybe the reason for firefox being so slow running this test is the compiler is not able to elliminate some of the allocations?
The java-code itself should be allocation-free except for the start of each benchmark round.

Comment 4

[stalkerg]

Matthew:
Looks like this code does next thing in the loop:

var rewrittenFunc = new Function('a', 'b', "_"+caller.name, rewrittenCaller);

I don't know how Chrome can optimize it.

Comment 5

[Mayank Bansal]

Is this fixed for you?

Comment 6

[Iain Ireland [:iain]]

I suspect that expanding the eval cache to also cover new Function would help a lot here.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.