Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Improve memory profiling doc #853

Merged
merged 2 commits into from
Jun 7, 2024
+13 −0
Merged

docs: Improve memory profiling doc #853

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0ae1070
docs: Improve memory profiling doc
jeromelaban Jun 7, 2024
e21725e
chore: Adjust wording
jeromelaban Jun 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions doc/features-profiling.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,19 @@ Note that as of .NET 6:
- The support for any timer based profiling is not supported, because of the lack of threading support in .NET
- The support for remote control of the profiler is not supported

## Memory Layout of a WebAssembly app

A WebAssembly app has multiple categories of allocated memory:

- The managed memory usage, which is the smallest portion of the overall used memory. This is the memory directly done by object allocations from managed code. It is the memory reported by `mprof-report` or the Xamarin Profiler. This memory can be queried by using the [`GC.GetTotalMemory`](https://learn.microsoft.com/en-us/dotnet/api/system.gc.gettotalmemory).
- The WebAssembly module memory usage, which is the overall app memory usage as far as WebAssembly is concerned. This is similar to the committed memory in a Windows app. This contains:
- The runtime's own native memory allocations
- The Garbage Collector memory, which is [directly impacted](xref:Uno.Development.Performance#webassembly-specifics) by the [GC parameters](https://learn.microsoft.com/xamarin/android/internals/garbage-collection#configuration).
- All the files located in the `Package_xxxx/managed` folder. Each assembly file is directly loaded in memory by the .NET runtime, regardless of it being used at the app's startup or not. Reducing the assemblies file sizes can be acheived by configuring the [IL Linker](xref:uno.articles.features.illinker).

The WebAssembly memory can be queried using the following JavaScript expression: `globalThis.Module.HEAPU8.length`, which gives the allocated memory in bytes. You can use [`JSImport`](xref:Uno.Wasm.Bootstrap.JSInterop#invoking-javascript-code-from-c) to read it from managed code.
- The javascript memory, which is mostly about the HTML DOM rendering and the browser's own runtime memory. Those two categories can be analyzed using the [browser's own debugging tooling](https://developer.chrome.com/docs/devtools/memory-problems).

## CPU Profiling

To enable the profiling of the WebAssembly code, set te following parameter:
Expand Down
Loading