Weird performance of blake3 depending on presence of Chrome Dev Tools

[nh2]

Hi, thanks for your very useful library. I hit the following puzzling issues:

On https://daninet.github.io/hash-wasm-benchmark/ the blake3 1 MB benchmark gives me ~400 MB/s in both Chrome and Firefox.

But if I open the dev toolbar in Chrome, performance drops to 40 MB/s; in Firefox its dev tools do not affect performance.

Video:

hash-wasm-blake3-chrome-performance-depends-on-devtools.mp4

---

It gets even weirder, but perhaps it's the same issue.

My minimal example https://nh2.me/js-file-reading/js-file-slice-blob-arrayBuffer-blake3.html reads an actual real file from disk (which is based on your StackOverflow example).
If I open this in Chrome in a completely new tab, and select a 200 MiB file with random contents, I get 160 MB/s.

However, if I open it in Chrome in a completely new tab, then toggle the Dev Tools on+off (pressing F12 two times), then I get only 40 MB/s.

This means that the performance drops 4x depending on whether the Dev Tools were opened in this tab in the past.

Refreshing the tab with F5 does not fix the performance, only closing it re-opening the tab fully fixes it.

Firefox does not have this problem; its performance is unaffected by the Dev Tools.

---

Note how the two pages are different:

• On your benchmark page, performance degrades only while Chrome Dev Tools are open; it recovers immediately once closed.
• On my sample page, performance stays bad even after Chrom Dev Tools are closed.

Any clue why this difference might exist? Perhaps it's because your benchmark page is hashing in a worker?

It would be great to find out how to achieve reliable high-performance blake3 hashing.

---

Browser versions:

• Chrome 111 on NixOS Linux, x86_64
• Firefox 111 on NixOS Linux, x86_64

Thanks!

[Daninet]

This is a known issue of the V8 JavaScript engine. Dev Tools disables certain WASM optimizations to enable support for debugging:
https://bugs.chromium.org/p/chromium/issues/detail?id=1226418#c14

This should not affect the average user, who doesn't even know where is the Dev Tool in Chrome.

[nh2]

@Daninet Ah thanks, I wasn't aware of that.

That ticket explains only my first issue though: Slow performance while Dev Tools are open. In the ticket they report that performance goes up again once Dev Tools are closed, without needing to close+reopen the tab.

For the example on my website though, the bad performance stays even after closing Dev Tools.

---

Tangentially related, do you have a recommendation on how to achieve max hashing performance when reading files from disk?

I get 350 MB/s disk-to-ArrayBuffer performance, and 400 MB/s blake3 performance (when the problem above is absent).

However, when combining reading from disk and hashing, throughput drops to 200 MB/s, even though IO and CPU should theoretically be independent.

I wonder why you used WebWorkers for your benchmark; did that make a big difference for you, or is it only to make your GUI and the computation logically independent?

Finally, another browser bug hit that you may want to be aware of, which I found when using your StackOverflow snippet on a Windows Share:
https://bugs.chromium.org/p/chromium/issues/detail?id=1427873

[nh2]

This should not affect the average user, who doesn't even know where is the Dev Tool in Chrome.

@Daninet Could you mention it on the main README though?

Otherwise lots of developers may, like me, waste time trying to find out why their use of hash-wasm is slower than expected, because many developers have the Dev Tools open most of the time.

[Daninet]

The bad performance stays even after closing Dev Tools.

My guess is that my benchmark behaves differently because I used web workers to do the hashing. Anyway this is an implementation detail in Chrome which might change at any moment. But apparently they don't put a lot of effort to fix this issue.

When combining reading from disk and hashing, throughput drops to 200 MB/s.

I had a quick look on your code and I think you can improve the performance by making the disk I/O work parallelly with the hash calculation.

for (let i = 0; i < numChunks; i++) {
  const buf = await chunkWithIndex(i).arrayBuffer();
   if (shouldHash) {
     hasher.update(new Uint8Array(buf));
   }
 }

Here, reading the buffer from disk blocks the hash calculation. And also the hash calculation blocks reading the next chunk from the disk. I would implement a stream with backpressuring support for the input data and move the hash calculation to a different web worker to not block the main thread of JS.

WebWorkers for your benchmark; did that make a big difference for you?

There should be no performance difference, but it's recommended to move heavy computation to a different thread to make the UI more responsive. Otherwise it might happen that the benchmark blocks the UI and you cannot stop the benchmark due to the frozen stop button.

Could you mention it on the main README though?

Yeah, it's a good idea. Thank you!

[nh2]

improve the performance by making the disk I/O work parallelly with the hash calculation

@Daninet Thanks for the tip, I did get ~30% better throughput by doing this (I put the hashing in a worker in this case).

Thanks for answering all my questions!