Re: [Mono-dev] profiling
Hi Neale, It is a concern as we addressed that issue over last year. If possible, could you file bugs with those .mlpd files attached so we can take a look? -- Rodrigo On Thu, Feb 25, 2016 at 3:18 PM, Neale Ferguson wrote: > Sometimes when we run the profiler and then run mprof-report we get > instances of “unresolved classes” in the report. How does this happen and > is it a concern? > > Neale > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] profiling
Sometimes when we run the profiler and then run mprof-report we get instances of “unresolved classes” in the report. How does this happen and is it a concern? Neale ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling API selective registration
disregard email. Thanks, Greg On Tue, Jan 5, 2016 at 5:28 PM, Greg Young wrote: > In dealing with very tight code and measuring mono we have found that > even registering empty handlers from a profiler can cost about 50% of > performance. Is there (or are there plans) for allowing a profiler to > selectively register to allow for better performance? From > benchmarking here a key one would be "no properties" as they tend to > be the ones where overhead is largest proportionally (and there are > tons of them). > > For most application scenarios we have tested there is no problem... > > Cheers, > > Greg > > -- > Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Profiling API selective registration
In dealing with very tight code and measuring mono we have found that even registering empty handlers from a profiler can cost about 50% of performance. Is there (or are there plans) for allowing a profiler to selectively register to allow for better performance? From benchmarking here a key one would be "no properties" as they tend to be the ones where overhead is largest proportionally (and there are tons of them). For most application scenarios we have tested there is no problem... Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling: Tail calls
There's nothing in it that handles tail calls specially. On Fri, Oct 16, 2015 at 8:20 AM, Greg Young wrote: > Is there anything to let you know that a tail call was made in the > profiling api? I haven't see anything so far but figured I might have > missed it. > > -- > Studying for the Turing test > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Profiling: Tail calls
Is there anything to let you know that a tail call was made in the profiling api? I haven't see anything so far but figured I might have missed it. -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling / Memory Management tools
THIS!! https://github.com/mono/mono/blob/master/data/mono.supp +1 On Sun, May 31, 2015 at 8:31 PM, Greg Young wrote: > Will read through but I am interested in the unmanaged side (part of > what I am working on is actually an injected profiler) > > Cheers, > > Greg > > On Sun, May 31, 2015 at 8:29 PM, Dan Liew wrote: >> On 31 May 2015 at 17:35, Greg Young wrote: >>> What tools are people using with mono? I have tried as an example >>> using valgrind to verify the stuff I am working on is reasonable but >>> the listings of problems that come out are massive. >> >> Checking the memory usage via valgrind will be pretty useless to you >> unless you know the mono internals. If you do want to continue down >> that route look at [1]. >> >> You're more likely to be interested in memory use at the level of your >> C#/F# code. To do this I've used mono's built-in memory profiling [2], >> e.g. >> >> $ mono --profile=log:heapshot my_program.exe >> >> You can specify how frequently shots of the heap are taken. You can >> view the result using mprof or heapshot [3]. >> >> [1] >> http://www.mono-project.com/docs/debug+profile/debug/#using-valgrind-on-mono >> [2] >> http://www.mono-project.com/docs/debug+profile/profile/profiler/#profiler-option-documentation >> [3] https://github.com/mono/heap-shot > > > > -- > Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling / Memory Management tools
Will read through but I am interested in the unmanaged side (part of what I am working on is actually an injected profiler) Cheers, Greg On Sun, May 31, 2015 at 8:29 PM, Dan Liew wrote: > On 31 May 2015 at 17:35, Greg Young wrote: >> What tools are people using with mono? I have tried as an example >> using valgrind to verify the stuff I am working on is reasonable but >> the listings of problems that come out are massive. > > Checking the memory usage via valgrind will be pretty useless to you > unless you know the mono internals. If you do want to continue down > that route look at [1]. > > You're more likely to be interested in memory use at the level of your > C#/F# code. To do this I've used mono's built-in memory profiling [2], > e.g. > > $ mono --profile=log:heapshot my_program.exe > > You can specify how frequently shots of the heap are taken. You can > view the result using mprof or heapshot [3]. > > [1] > http://www.mono-project.com/docs/debug+profile/debug/#using-valgrind-on-mono > [2] > http://www.mono-project.com/docs/debug+profile/profile/profiler/#profiler-option-documentation > [3] https://github.com/mono/heap-shot -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling / Memory Management tools
On 31 May 2015 at 17:35, Greg Young wrote: > What tools are people using with mono? I have tried as an example > using valgrind to verify the stuff I am working on is reasonable but > the listings of problems that come out are massive. Checking the memory usage via valgrind will be pretty useless to you unless you know the mono internals. If you do want to continue down that route look at [1]. You're more likely to be interested in memory use at the level of your C#/F# code. To do this I've used mono's built-in memory profiling [2], e.g. $ mono --profile=log:heapshot my_program.exe You can specify how frequently shots of the heap are taken. You can view the result using mprof or heapshot [3]. [1] http://www.mono-project.com/docs/debug+profile/debug/#using-valgrind-on-mono [2] http://www.mono-project.com/docs/debug+profile/profile/profiler/#profiler-option-documentation [3] https://github.com/mono/heap-shot ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Profiling / Memory Management tools
What tools are people using with mono? I have tried as an example using valgrind to verify the stuff I am working on is reasonable but the listings of problems that come out are massive. -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Profiling
I was reading through the 1.2 release notes (http://www.go-mono.com/archive/1.2/) and I just realized there is a broken link that should point to "performance tips". ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling output
Excellent. That's exactly what I was looking for. Thanks. /Jacob On 3/24/06, Paolo Molaro <[EMAIL PROTECTED]> wrote: > On 03/23/06 Jacob Ilsø Christensen wrote: > > I have been experimenting a bit with monos profiling option. I run > > mono like this: > > > > mono --profile=default:time A.exe > > > > This results in the profiling information being printed to stdout. Is > > there a way to redirect this information to e.g. a file to prevent it > > from being mixed with the output from the program (A.exe) itself? > > I just added the feature to svn, use the file option: > > mono --profile=default:time,file=prof.out A.exe > > lupus > > -- > - > [EMAIL PROTECTED] debian/rules > [EMAIL PROTECTED] Monkeys do it better > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Profiling output
On 03/23/06 Jacob Ilsø Christensen wrote: > I have been experimenting a bit with monos profiling option. I run > mono like this: > > mono --profile=default:time A.exe > > This results in the profiling information being printed to stdout. Is > there a way to redirect this information to e.g. a file to prevent it > from being mixed with the output from the program (A.exe) itself? I just added the feature to svn, use the file option: mono --profile=default:time,file=prof.out A.exe lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Profiling output
Hi. I have been experimenting a bit with monos profiling option. I run mono like this: mono --profile=default:time A.exe This results in the profiling information being printed to stdout. Is there a way to redirect this information to e.g. a file to prevent it from being mixed with the output from the program (A.exe) itself? /Jacob ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
