[docs] begin documenting how to use EventPipe-based profiled AOT for Mono #72864
Conversation
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
lambdageek
added
documentation
lambdageek
force-pushed
the
profiled-aot-docs
branch
from
8842660
to
14b6515
Compare
|
|
||
| Specify `"suspend": true` to suspend the runtime at startup (**NOTE** this will make the browser unresponsive until a diagnostic tool connects and resumes it.) The URL has to use the `ws://` scheme (`wss://` is WIP) the host should be a localhost, the port can be arbitrary, and the path `/diagnostics` is arbtrary, too. | ||
|
|
||
| 2. Run `dotnet-dsrouter server-websocket -ws http://127.0.0.1:[port]/diagnostics -ipcs /path/to/domain_socket` the `-ws` URL should be the same as the `connect_url` in the .csproj, but with the `http://` scheme. The `-ipcs` option is some arbitrary path. |
There was a problem hiding this comment.
nit: since its server-websocket maybe put -ipcs argument first and then -ws
btw, should we prepare to handle web socket client as well (not implement anything, just make sure we name things accordingly)? If so, maybe we should use names like -wss and potential -wsc in the future (websocket client), and maybe still use server-server but when using -wss it will use web socket and using -tcps using tcp server?
There was a problem hiding this comment.
btw, should we prepare to handle web socket client as well (not implement anything, just make sure we name things accordingly)?
I'm not sure that a websocket client mode makes sense. Websockets are asymmetrical - the browser starts the connections to other hosts. There is no mechanism for a browser to listen for connections.
| @@ -474,6 +515,39 @@ TraceEvent library, https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing | |||
|
|
|||
| https://github.com/lateralusX/diagnostics-nettrace-samples includes a couple of custom tools (startup tracing, instrumented method execution, GC heap dump analysis) analyzing nettrace files using TraceEvent library. | |||
|
|
|||
| ## Profiled AOT using `dotnet-pgo` | |||
|
|
|||
| By collecting a .nettrace file using the diagnostic server and EventPipe, it is possible to create `.mibc` files using the `dotnet-pgo` tool that can be used to tell the Mono AOT compiler which methods in an applcation should be compiled with AOT and which should be interpreted or JITed. A typical use-case is to improve the startup performance of a mobile app, or to control the overall size of an AOTed application. | |||
There was a problem hiding this comment.
| By collecting a .nettrace file using the diagnostic server and EventPipe, it is possible to create `.mibc` files using the `dotnet-pgo` tool that can be used to tell the Mono AOT compiler which methods in an applcation should be compiled with AOT and which should be interpreted or JITed. A typical use-case is to improve the startup performance of a mobile app, or to control the overall size of an AOTed application. | |
| By collecting a .nettrace file using the diagnostic server and EventPipe, it is possible to create `.mibc` files using the `dotnet-pgo` tool that can be used to tell the Mono AOT compiler which methods in an application should be compiled with AOT and which should be interpreted or JITed. A typical use-case is to improve the startup performance of a mobile app, or to control the overall size of an AOTed application. |
| dotnet-pgo create-mibc --trace <file.nettrace> | ||
| ``` | ||
|
|
||
| and pass the resulting `.mibc` file to the Mono AOT compiler MSBuild task using the `MibcProfilePath` property, |
There was a problem hiding this comment.
Didn't we need to pass in a path to the assemblies used producing the .nettrace files to dotnet-pgo, @mdh1418?
There was a problem hiding this comment.
Yea this is incomplete. I need to update this with the actual instructions
|
|
||
| Specify `"suspend": true` to suspend the runtime at startup (**NOTE** this will make the browser unresponsive until a diagnostic tool connects and resumes it.) The URL has to use the `ws://` scheme (`wss://` is WIP) the host should be a localhost, the port can be arbitrary, and the path `/diagnostics` is arbtrary, too. | ||
|
|
||
| 2. Run `dotnet-dsrouter server-websocket -ws http://127.0.0.1:[port]/diagnostics -ipcs /path/to/domain_socket` the `-ws` URL should be the same as the `connect_url` in the .csproj, but with the `http://` scheme. The `-ipcs` option is some arbitrary path. |
There was a problem hiding this comment.
Would it make sense to actually use the same connect_url as configured as diagnostic_options? I think that would make things clearer and reduce risk of copy/past errors and forget to change ws(s) to http(s).
There was a problem hiding this comment.
This all changed too. It's now controlled by the DOTNET_DiagnosticPorts environment variable
|
I'm going to change this to draft for now and rework it to include the changes from the past month of work |
ghost
closed this
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
ghost
locked as resolved and limited conversation to collaborators
Also document how to use diagnostics with WebAssembly