gauravdewan007@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

The component is v8 Javascript-Webassembly. 

The bug happens in normal webworker (not service worker) 

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

gauravdewan007@ - Could you please provide a sample webworker test file to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

1)Attached is Worker.zip. Unzip it to a folder worker\ and run http-server -p 8001 in that folder.
2)In chrome 64 browser goto localhost:8001/a.html and note the difference of last timestamp and first stamp shown in console
3)Repeat for chrome 63 and note the difference of last timestamp and first timestamp shown in console
Note that timings in chrome 64 is 3 times the timing observed for chrome 63.

Perhaps it is fixed in chrome 66. Please let us know. Thanks

Deleted: worker.zip 445 KB

worker.zip 445 KB Download

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

CC: ahaas.

This is probably due to W^X with --wasm-jit-to-native, but needs to be confirmed.

This issue was happening across platforms

Can we get the fix ported in next dot release of chrome? 
Also note that using this same test case (worker.zip)  following Mac specific issues can be easily reproduced:
https://bugs.chromium.org/p/chromium/issues/detail?id=753985

This wasm module has 11017 functions (wasm not asm.js), that would presumably be impacted by W^X quite a bit.

In 66.0.3346.8 on Linux 64 I'm seeing this:
--no-wasm-jit-to-native --write-protect-code-memory --- ~7300
--no-wasm-jit-to-native --no-write-protect-code-memory --- ~4800
--wasm-jit-to-native --no-write-protect-code-memory --- ~1150
--wasm-jit-to-native --write-protect-code-memory --- ~1200

Looks like we're seeing a problem with W^X (seems like jit-to-native reduces this, which makes sense).
Are we cherrypicking turn that off to all the branches?

Unable to reproduce the issue on Win-10 and mac 10.12.6 using chrome stable #64.0.3282.167 and latest canary #66.0.3350.0.

Attached a screen shots for reference.

Following are the steps followed to reproduce the issue.
------------
1. Opened a.html file after unzipping worker.zip file from comment #7 using http server command.
2. Did not observe timings in chrome 64 as 3 times the timing observed for chrome 63. There is not much difference in chrome 64 and chrome 63 timings.

gauravdewan007@ - Could you please check the attached screen shots and please let us know if anything missed from our side. Also if possible please provide a screen cast/screenshot for better explanation of the issue. This will help us in triaging the issue further.

Thanks...!!

Deleted: 811373@M64.PNG 117 KB

	811373@M64.PNG 117 KB View Download

Deleted: 811373@M63.PNG 115 KB

	811373@M63.PNG 115 KB View Download

Re #12: Yes, we are planning to remove W^X from "wasm-jit-to-native" and cherry-pick that to M65. Tracking bug is in issue v8:7454. Note that "wasm-jit-to-native" is on by default in M65 (and tip-of-tree).

Re #13 you need to wait few seconds and then subtract the first timestamp (html time) from last timestamp displayed on console(which is missing from screenshots) to note the total time taken. This will show a difference of 300% or so. 
Also as per #12 the issue is reproducible.  

Hi,

We're seeing this slow down with Mono where load times with chrome/v8 are 30x slower than compared to other browsers.

It takes about 12s to construct the module and then 233ms to instantiate it.

As a reference point timing from other engines looks like this:

Chakra takes 180ms to construct and 25ms to instantiate.
SpiderMoney takes 140ms to construct and 2ms to instantiate.
JavaScriptCore takes 55ms to construct and 2.2s to instantiate.

This is effectively blocking usage of mono+wasm on chrome.

This was tested with V8 version 6.8.63, OSX, using the shell driver.

To reproduce our issue, please pick one of our packages from here: https://jenkins.mono-project.com/job/test-mono-mainline-wasm/
IE: https://jenkins.mono-project.com/job/test-mono-mainline-wasm/75/label=ubuntu-1804-amd64/Azure/processDownloadRequest/75/ubuntu-1804-amd64/sdks/wasm/mono-wasm-8d1c93e563b.zip

The load/instantiate delta is about 10x better the mono.wasm in release/ compares to debug/

How big are the modules you are compiling and are you running a debug build?

We are working on a baseline compiler that we hope to launch soon. Are you able to try your examples with --liftoff?

gauravdewan007 and kumpera: Do you have DevTools open when you do these measurements? When DevTools are open, WebAssembly compilation reports debug information to DevTools, which unfortunately introduces quite some overhead at the moment. When I open DevTools only after WebAssembly compilation is finished,  performance is actually much higher and in the same order of magnitude as other browsers in my experiments.

Other than the DevTools issue I cannot reproduce this issue.

@ahaas The original bug I reported was regression specific to chrome 64 (related to w^x) and was fixed in chrome 65. 

The mono issue reported in #16 seems to be separate loading (performance) issue. 
Also the OSX specific issue (an old issue) is logged separately as https://bugs.chromium.org/p/chromium/issues/detail?id=753985

@gauravdewan007 Does this mean that this issue can be closed? I'm not sure I understand your comment #21.

yes the issue can be closed as fixed