Performance difference between spawn/spawn_blocking on web target.

[control9]

Hello! First of all, let me thank you for the wonderful framework, it's been truly a bliss to get started with it.
I have been evaluating whether it would be a good fit for my use case (GUI for existing CPU/memory intensive code in Rust), and while fiddling with web target I have noticed some interesting behaviour, indicating that I might be not getting the best possible performance.

I have stubbed some CPU-intensive piece of calculation, trying to ensure that it is not getting optimized out (iterating over 1..n checking 3n+1 hypothesis), and build very simple UI with a button to trigger it. When I do it on desktop build I get around 3.5 seconds of execution time - that would be a baseline. On web for the same code I get around 9s on first execution and then it drops under 4s on further ones -- I guess some optimizations are kicking in on the fly - couldn't find any information if Chrome does any JIT-like optimizations for WASM code.
But then I realized that I using tokio spawn results in blocking UI during execution, an switched to spawn_blocking, which, according to https://github.com/cunarist/tokio-with-wasm moves it to web worker. As a result, there was no change in performance on desktop, but for web execution time now stays around 9s even for repeated executions. I have tried to ensure that it is not due to new worker getting activated on each attempt, by running task via spawn_blocking at app start and passing actual requests for calculations to it via tokio mpsc - no impact.

I was wondering whether there might be some additional guidelines in order to achieve same performance in workers as when using browser's event loop, or whether something in current implementation of tokio-with-wasm may be preventing them from happening.

[control9]

To answer my own question (and, hopefully, save someone from spending couple of evenings debugging the issue), there were two separate reasons for slowdown, which I was triggering occasionally, and, ironically, my attempts to add more logging or do profiling made situation worse.
Reason 1: Opening dev tools. Expected behaviour, however, as per V8 docs. Googling for "Chrome wasm JIT" was not very efficient, so it took me some time to catch this one, and "profiling" section is what made it even more fun, as during profiling all code suddenly got tiered up, eliminating the issue.
Reason 2: While trying to fix the issue, I switched to having single worker in a loop waiting for message in channel to start calculation. Per same docs, "we don’t do on-stack-replacement" - so wasm function was stuck running in low-tier compiled mode, as TurboFan compilation only started after it was called and identified as "hot". That is why I ended up with an impression that it is caused by spawn_blocking.

TL;DR: Opening dev tools degrades WASM performance; running loop in a function instead of spawn/spawn_blocking it on each call degrades performance if function ends up called only once.