Dan Schnau

Experimenting with performances gains from Blazor WASM AOT Compilation 2.0

In my previous post I had left open a problem of a 100ms delay that forced the screen to repaint.

I've been working out what is required to make sure the screen paints between each assignment of a new Base64 to the <img> tag in the DOM.

After some discussion in Discord with Marek FiĊĦera, I've gotten the "forced delay" down to a single millisecond:

private async Task DrawStar()
{
    using (Image<Rgba32> image = new(TimesCompleted * 10, 200))
    {
        Star star = new(x: 100.0f, y: 100.0f, prongs: 5, innerRadii: 20.0f, outerRadii: 30.0f);
        image.Mutate(x => x.Fill(Color.Red, star));
        ImgString = image.ToBase64String(JpegFormat.Instance);
    }
    TimesCompleted++;
    StateHasChanged();
    await Task.Delay(1);
    await Task.Yield();
}

As a result, I get a more accurate picture of JIT vs AOT compilation for this little test case.


JIT:

> AOT - and take note, AOT compilation takes a long time! This little app took 6 minutes and 14 seconds to compile: > And now the performance difference is **five-fold**!

Update 1/23/24: while browsing the Fediverse this morning, I found a much more comprehensive investigation of Blazor's WASM performance by one Kristoffer Strube.