Performance issue: Why Blazor Web assembly loop is far slower than Javascript?

[madnik7]

I have created two simple loops in Javascript and Blazor WebAssembly. I was going to love Blazor and had expected web assembly to be faster because it was compiled and optimized, but it was far slower than Javascript. I used .NET 6 Blazor web assembly. Did I do something wrong or Blazor is not designed for this scenario at all?

Javascript: 3 seconds

Blazor: 95 seconds

Javascript:

function Foo() 
{
  let fruit = [];
  for (var i = 0; i < 5000000; i++) {
    fruit[i] = "zzzz" + i.toString() + "yyy" + i.toString() +
      i.toString() + i.toString() + i.toString();
  }

  let counter = 0;
  for (var j = 0; j < fruit.length; j++)
    if (fruit[j].indexOf("111") > 0)
      counter++;
  console.log(counter);
}

Blazor Web assembly:

void Foo()
{
    DateTime dateTime = DateTime.Now;
    var items = new string[5000000];
    for (var i=0; i<items.Length; i++)
        items[i] = "some string some string 111" + i.ToString();

    var counter = 0;
    for (var i = 0; i < items.Length; i++)
        if (items[i].IndexOf("111") > 0)
            counter++;
}

[javiercn]

@madnik7 thanks for contacting us.

Are you running the published Ahead of Time compiled app in Release mode?

[madnik7]

Thank you for replying.
No, it was off. But now I have turned it on, but the performance is still the same. I have also created a new Blazor project with VS2022 .NET 6 default template and turned AOT on in release mode, then run it, but the performance is still the same. Tested on the latest version of EDGE and Chrome.

It looks like any string manipulation or compression drastically degrade the performance. Is it normal?

[TanayParikh]

How are you measuring the time for JS / Blazor. It's not immediately clear based on the snippet you provided. Also, just confirming you do NOT have the debugger attached, correct?

[madnik7]

I use a simple timer and alert to measure time. Also I "start without debugging" and the browser console is off

    private void Foo()
    {
        DateTime dateTime = DateTime.Now;
        var items = new string[5000000];
        for (var i = 0; i < items.Length; i++)
            items[i] = "some string some string 111" + i.ToString();

        var counter = 0;
        for (var i = 0; i < items.Length; i++)
            if (items[i].IndexOf("111") > 0)
                counter++;
        
        JsRuntime.InvokeVoidAsync("alert", (DateTime.Now - dateTime).TotalSeconds.ToString()); // Alert
    }

[azbo]

这个差距有点大

[azbo]

65 times the gap in my machine

[madnik7]

I had to publish the project to get benefits from AOT. Now the performance gets 5x faster, but still, Blazor code is almost 3x slower than javascript.

Javascript: 3 seconds
Blazor: 10 seconds

I really like Blazor, but the performance is disappointing. I've come from VueJS, Now I can completely feel the amount of lag in my Blazor project even though my project is very small now. I hope there is a solution to this performance.

[azbo]

500000
.net core console:1.65s
java:0.27s
javascript:0.203s

.net core console

java:

javascript:

[azbo]

我使用一个简单的计时器和警报来测量时间。此外， 我 "开始不调试" 和浏览器控制台关闭

    private void Foo()
    {
        DateTime dateTime = DateTime.Now;
        var items = new string[5000000];
        for (var i = 0; i < items.Length; i++)
            items[i] = "some string some string 111" + i.ToString();

        var counter = 0;
        for (var i = 0; i < items.Length; i++)
            if (items[i].IndexOf("111") > 0)
                counter++;
        
        JsRuntime.InvokeVoidAsync("alert", (DateTime.Now - dateTime).TotalSeconds.ToString()); // Alert
    }

我在 Javascript 和布拉佐网络组装中创建了两个简单的循环。我本想爱布拉佐尔，并期望网络组装更快，因为它是汇编和优化，但它比Javascript慢得多。我用. NET 6 布拉佐尔网络组装。我做错了什么还是布拉佐根本不是为这种情况设计的？

爪哇脚本：3秒

布拉佐尔： 95 秒

爪哇脚本：

function Foo() 
{
  let fruit = [];
  for (var i = 0; i < 5000000; i++) {
    fruit[i] = "zzzz" + i.toString() + "yyy" + i.toString() +
      i.toString() + i.toString() + i.toString();
  }

  let counter = 0;
  for (var j = 0; j < fruit.length; j++)
    if (fruit[j].indexOf("111") > 0)
      counter++;
  console.log(counter);
}

布拉佐尔网络装配：

void Foo()
{
    DateTime dateTime = DateTime.Now;
    var items = new string[5000000];
    for (var i=0; i<items.Length; i++)
        items[i] = "some string some string 111" + i.ToString();

    var counter = 0;
    for (var i = 0; i < items.Length; i++)
        if (items[i].IndexOf("111") > 0)
            counter++;
}

我使用一个简单的计时器和警报来测量时间。此外， 我 "开始不调试" 和浏览器控制台关闭

    private void Foo()
    {
        DateTime dateTime = DateTime.Now;
        var items = new string[5000000];
        for (var i = 0; i < items.Length; i++)
            items[i] = "some string some string 111" + i.ToString();

        var counter = 0;
        for (var i = 0; i < items.Length; i++)
            if (items[i].IndexOf("111") > 0)
                counter++;
        
        JsRuntime.InvokeVoidAsync("alert", (DateTime.Now - dateTime).TotalSeconds.ToString()); // Alert
    }

items[i].IndexOf change items[i].AsSpan()

[azbo]

DateTime dateTime = DateTime.Now;
var items = new string[500000];
for (int i = 0; i < items.Length; i++)
{
items[i] = $"some string some string 111{i}";
}

    var counter = 0;
    for (var i = 0; i < items.Length; i++)
    {
        if (items[i].AsSpan().IndexOf("111") > 0)
        {
            counter++;
        }
    }

    Console.WriteLine($"耗时 {(DateTime.Now - dateTime).TotalSeconds} s");
    Console.WriteLine(items.Length);

[javiercn]

@madnik7 I don't think this type of benchmark is super relevant.

I suspect the JS implementation is able to internally use SIMD, hence the speed-up, and the .NET runtime doesn't leverage SIMD on WASM yet. Other things that might be affecting the benchmark might be the fact that you are forcing .NET to initialize a large array (5 million elements), which can probably be avoided with [SkipLocalInits]

In the JS case you are actually "mostly" not running JS, since the toString(), indexOf(), and other functions are natively implemented by the browser. A more fair comparison would be if you were to put the strings in arrays and perform the indexOf and toString() operations within JS.

That said, there are always going to be microbenchmarks where you can bet the WASM code, the reality is that all it matters is what works for your app. I would suggest you try to build something realistic that you would use in real-life and check if you have performance problems with it or if the trade-off against performance works for you or not and decide based on that.

After all, we are also a great backend for other JS frameworks 😉 and you can mix and match Blazor with them too!