Performance of code in Blazor is extremely poor (~200x slower than on desktop)

[a-student]

This is a duplicate of this issue. I have created the duplicate with the hope that experts here can help me to tune the performance of the code build with Blazor. I am using Blazor version 0.3.0.

It is stated here that

WebAssembly aims to execute at native speed

Therefore, mono-wasm is expected to perform nearly the same as on desktop. Unfortunately, mono for WebAssembly is far away in performance than expected, it is on average 200x slower.

Consider this code:

var sw = Stopwatch.StartNew();
var a = Math.PI;
for (var i = 0; i < 1080; i++) {
    for (var j = 0; j < 1000000; j++) {
        a += Math.PI;
    }
}
Console.WriteLine("Elapsed " + sw.Elapsed);

It prints Elapsed 00:00:00.9990513 when running in .NET Core Elapsed 00:00:02.9962702 when running in mono on desktop Elapsed 00:21:38.9038000 when running in Blazor (Google Chrome browser). This is >400x slower than mono on desktop!

The same code in JavaScript shows almost the same performance as in .NET Core:

let t = performance.now();
let a = Math.PI;
for (let i = 0; i < 1080; i++) {
    for (let j = 0; j < 1000000; j++) {
        a += Math.PI;
    }
}
t = performance.now() - t;
console.log("Elapsed " + t + " milliseconds");

It prints Elapsed 1179.1999999986729 milliseconds

By the way, mono-wasm in the latest Firefox shows better performance than in Chrome (Elapsed 00:01:13.5770000), but still very slow on average.

So my questions are:

1. Why mono-wasm is too slow?
2. Is it possible to tune its performance somehow?

My environment: Hardware: ThinkPad X1 Carbon (2nd Gen), CPU: 4th Gen Intel® Core™ i7-4600U (3.30GHz 1600MHz 4MB) OS: Windows 10 Pro 64-bit 1803 Browser: Google Chrome 66.0.3359.181 (Official Build) (64-bit) Mono-wasm from this package Mono for desktop version 5.12.0 Stable (5.12.0.226) 64-bit .NET Core version 2.1.300-preview2-008533

[danroth27]

@kumpera

Yes, our current runtime an unoptimized interpreter. Significant slowdown compared to peak desktop perf is expected at this point given the experimental nature of Blazor and the underlying bits.

We hope to really start seeing the perf benefits of WebAssembly when we have support for static ahead-of-time (AoT) compilation to WebAssembly for .NET, but that's still being worked on.

Closing this as the main perf feedback is most relevant to the Mono team.

[a-student]

If you mean by static AOT compilation this project - it seems dead - no commits for almost 4 months. Blazor has a great idea and it's a wonderful project, but as long as it is based on a raw mono-wasm, it will still be "experimental" :(

[Suchiman]

@a-student if you take a closer look, that repository doesn't actually contain most src code, mono wasm is maintained upstream in https://github.com/mono/mono

[a-student]

@Suchiman mono-wasm at official mono repository has JIT, which is unfortunately very slow. Is there AOT compilation for WebAssembly?

[rvhuang]

May I know why the issue is closed? Please at least keep the issue open so we can track the progress.

[danroth27]

It's closed because the work to be done is in mono, not in Blazor.

[codec-abc]

Hi, quick questions here:

1. Is the Mono issue tracking AoT compilation for WASM is this one?
2. This may be dumb but since WebAssembly can generate at runtime WebAssembly code that can be run, is it feasible (and somehow easier to do) to generate more efficient wasm code at runtime?

[steve-potts]

pointless anyway, with vue around, learn it in a day or two, no need to learn TS etc, amazing performance and around 16kbit?

[GoranHalvarsson]

Not pointless, that IS the whole point to NOT use any javascript libraries/frameworks. Do it all in c#...

[steve-potts]

but why. c sharp always sucked. at least for web. no one ever used it. there's a reason iis has 10% share. everyone who had any real web apps went to php js ruby whatever. c sharp has never been anywhere on the web . why limit yourselves to ms crappy tools. crappy webservers

[xclud]

@coolpot Yeah C# have had a bad reputation for many years for webservers (Specially in WebForms era). But this has changed in .NET Core. Just take a look, give it another chance to prove itself. C# is now outperforming other platforms/languages. It is even Linux compatible today.

[steve-potts]

xclud you probably said it in a better way. the problem is I've looked at core too and it's typical Microsoft. broken frameworks. every version breaks or changes everything. I've given them so many chances in the past. and sure core is a lot better. but I do get fed up with like core 2 then core 2.1 comes out and they have put things like authentication stuff in a dll or whatever. then okay you can scaffold it out. but that failed. turned out you need to run visual studio update. then it fails still. only works with new projects. like everything feels so in progress and broken.

my point is. Blazor offers nothing new that you can't do elsewhere except it's unfinished and has massive warnings not to use it.

[xclud]

I agree with you, but at the same time i believe Blazor (both Server-side and Client-side) is the future. Soon we will see PHP, Ruby and etc will copy from MS. It is not the first time MS is being copied and will not be the last.

but I do get fed up with like core 2 then core 2.1 comes out and they have put things like authentication stuff in a dll or whatever. then okay you can scaffold it out. but that failed. turned out you need to run visual studio update.

It is not just C# and .NET Core. this is a global problem in whole Microsoft company. I no longer see Microsoft as a USA-grade-standard company since Nadella came as CEO. Even Windows 10 looks incomplete, untested, in progress and never-finishing.

Anyway, i believe C# is still C# and i am looking forward to Blazor and the next ASP.NET Core. I am already porting my projects to nightly builds!! of Blazor.

Lets not chat here :) bro.

[a-student]

After spending a lot of time on trying Blazor without lack, I switched to TypeScript + React. @xclud if you mean the same language on frontend and backend – typescript / javascript is the future. There are many beautiful production-ready tools, such as Gatsby or Next.JS (using React SSR and single language / technology on the client and server). By the way, if you know C# - you already know TypeScript.

I no longer see Microsoft as a USA-grade-standard company since Nadella came as CEO

I would not blame any CEO, Microsoft has always been like that. When I was in the past engaged in development for Windows Phone, I spent 90% of the time on fixing bugs and searching for workarounds. Switching to Android development was like a breath of fresh air where you spend 90% of your time on creating new features.

[xclud]

@a-student I believe it is too early to judge Blazor. For SSR It is not even in Alpha state and even not released. React for example is lunched for years now with more than 16 major releases and breaking previous libraries (Why nobody see this?). And for client-side we just know there is something just like a name and few pieces of information.

After spending a lot of time on trying Blazor without lack, I switched to TypeScript + React.

Just think how great is something even not lunched and you spent a lot of time on it. I am asking you if you would spend this time on React months before its 1st version. And asking myself if i would switch to it after 16 major releases. Both answers are No i guess.

I love Blazor not only for using the same language on client and server side. But also because it is C#. I already know TypeScript and have had years of JS job. Also, unlike other frameworks, Blazor does not work by querying data and fillng the empty, but it works by sending async messages to the server and receiving async messages from server, thanks to SignalR.