Transfer rate for RESOURCE schema type is prohibitively slow

[RobertBouillon]

My Blazor app compiles an 86MB file using .NET AOT compilation.

Chromely takes ~66 seconds to load the file from disk using the RESOURCE Url scheme.

Is it possible to improve the performance here?

[mattkol]

@RobertBouillon Blazor WebAssembly or Blazor Server? I am assuming WebAssembly. It may not be unexpected because of all the dlls that would need loading before rendering.

I quick alternative check would be to try the "File Protocol" https://github.com/chromelyapps/Chromely/blob/master/Documents/loading_html.md#file-protocol. Note that this is not recommended.

A nicer solution would be to explore Blazor lazy loading - https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-lazy-load-assemblies?view=aspnetcore-6.0 https://code-maze.com/lazy-loading-in-blazor-webassembly/

[RobertBouillon]

Pure WASM. Takes ~12 seconds when hosted and ~66 seconds in Chromely. Looks like it's bottlenecked @ 1024kbps transfer rate? Was hoping it would be faster loading locally - didn't expect it to be slower.

File protocol doesn't work. Only takes a couple seconds when not using AOT - in that case it's loading lots of small files instead of one large one.

[mattkol]

@RobertBouillon it may help too to confirm how and what files are being loaded.

You can track that here: https://github.com/chromelyapps/Chromely/blob/542cd54d2a5452dd67d45aef0054f6187f17f809/src/Chromely/Browser/Handlers/DefaultResourceSchemeHandler.cs#L43

If you need to create a custom resource handler, there is a sample here: https://github.com/chromelyapps/Chromely/issues/244#issuecomment-877643819

[RobertBouillon]

Awesome - thanks for the help. Pointed me in the right direction. After digging a little, it looks like the source of the problem is actually in CefGlue - the resource handler just hands off a buffer and something lower-level marshals it to Chromium. I didn't dig too much, but my guess is it needs a bigger buffer and / or double buffering.

Not sure if the bottleneck is CefGlue or part of the NetStandard wrapper.

The goal was to shift to AOT to get some better performance, but this looks like a rabbit hole. Since the performance right now is "good enough", I'll probably just document this and move-on.

[mattkol]

Yes, "bytesToRead" buffer size limitation. Apologies, I forgot that, been a while.

From: https://groups.google.com/g/cefglue/c/0_bJabHCjbI

CEF reads stream by small portions (about 4KB) - and indicate how much data you must write into the stream in bytesToRead argument.

I doubt there is a known way to change the buffer size...

From: https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=12118&p=22746&hilit=chunk#p22746

This is similar to the issue: https://www.magpcss.org/ceforum/viewtopic.php?f=14&t=18051&p=47821&hilit=bytesToRead#p47821

Note: I did not check what the current buffer size is.