User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15

Steps to reproduce:

open this page
open Web Console devtool
select a large file (I tested files which are 10 ~ 30MB)
observe the console output.

the source is here.

Actual results:

the function used async is about slower than the function without async.( x100 slower on my machine(macOS) )

This is because async functions can't be Ion-compiled. The code being timed is:

    for (let index = 0; index < uin8array.length; index++) {
      uin8array[index] ^= key;
    }

For what it's worth, hufan.akarin, you can make it fast by factoring this code out into a separate non-async function.

I just tried to reproduce this bug. When I uploaded a file of 60 MB into the linked codepen, I saw the following result:

handleFilePromise: 5783.72216796875 ms
handleFileAsyncAwait: 1226.853759765625 ms

Does this mean the async/await is actually faster?

with bug 1682623, async function is now optimized.
and the testcase doesn't use await in the hot path, so the performance should be almost same as regular function.

I used 20MB file and 50MB file, and I see almost same time between them (~500ms and ~900ms).

Then, for the testcase, if you use large file and if it takes more than 1000 ms,
you'll see "This page is slowing down ..." bar at the top of the page.
This is triggered by firefox if the script runs too long without returning, to allow users to stop the script.
During showing the bar, the current execution is de-optimized, and the result time isn't reliable.