Profiling application under Wine

[Chambers, Matthew]

To use this I would have to self-host mono, right? I'm currently just relying on the compiler to add the .NET build-up/tear-down.

I was finally able to get VsPerfCollectionTools working for trace mode under wine, but not sampling mode. It required using vsinstr to 
instrument the binary, and I had to be careful about which functions I allowed to be instrumented. It seems if I let it instrument any .NET 
functions (with funcspecs like "my.nested.namespace.*" instead of "my::nested::namespace::*"), it would crash. But I was at least able to 
instrument C++ functions.

Thanks for all the suggestions though everyone!
-Matt


On 7/1/2019 4:49 AM, Hin-Tak Leung wrote:
> This is the relevant part of the documentation. So presumably you can do MONO_ENV_OPTIONS="--profile" and 
> MONO_ENV_OPTIONS="--profile=stuff" , I believe.
>
> ===
>
> DEVELOPMENT OPTIONS
> ...
> --profile[=profiler[:profiler_args]]
> Loads a profiler module with the given arguments. For more information, see the PROFILING section. This option can be used multiple times; 
> each time will load an
> additional profiler module.
>
> ENVIRONMENT VARIABLES
> ...
> MONO_ENV_OPTIONS
> This environment variable allows you to pass command line arguments to a Mono process through the environment. This is useful for example 
> to force all of your
> Mono processes to use LLVM or SGEN without having to modify any launch scripts.
> ===
>
> On Friday, 28 June 2019, 19:09:22 BST, Vincent Povirk <madewokdev at gmail.com> wrote:
>
>
> The WINE_MONO_* variables are just the ones we've added. Other MONO_* variables should generally work the same as in regular Mono. I 
> haven't worked with Mono's profiling tools so I can't give any further advice.
>
> On Fri, Jun 28, 2019, 11:18 AM Hin-Tak Leung <htl10 at users.sourceforge.net <mailto:htl10 at users.sourceforge.net>> wrote:
>
>     Hmm, I think wine-mono has been working in 64-bit mode for a while - although you have to invoke wine explicitly as wine64 to hook
>     into it . I think there are some quirks about how wine and wine-mono interacts, in such a way that you cannot do 32-bit + 64-bit
>     switches within the process - i.e. you must do 64-bit wine to get at 64-bit wine-mono.
>
>     Do you notice any performance difference between using wine-mono and dotnet472 64-bit ?
>
>     I am going back to wine-mono for your issue, as mono supports setting profiling option via environment variables (catering for exactly
>     this use case, when mono is running embedded inside another process), and you can set WINE_MONO_* variables to pass those along. I am
>     not sure about the exact details so you'll need to look up the relevant docs, but I know this is possible - mono has a built-in
>     profiler, and it is accessible and turned on via environment variables.
>
>     --------------------------------------------
>     On Tue, 25/6/19, Chambers, Matthew <matt.chambers42 at gmail.com <mailto:matt.chambers42 at gmail.com>> wrote:
>
>      The application requires
>      dotnet472 and 64-bit at that. I actually had to add that
>      verb to winetricks to get our application to work. I'm
>      definitely getting varying mileage! My
>      question is how to profile it with Windows symbols so I can
>      understand why and either help fix it in
>      Wine or possibly avoid the problem from my
>      application code.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190701/ec1d7148/attachment.html>