profiling code

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
stijn
Posts: 23
Joined: Thu Jun 28, 2007 2:57 pm

profiling code

Post by stijn » Wed Oct 17, 2007 1:59 pm

Hi,

When I profile code, I use 2 different methods, according to the suspected leak :
for some I just run my code in debugger, and profile by attaching the profiler to the process,
this has the advantage, that I can actually trace into the code , and make some changes to it , without actually restarting the application , by using the VS2005 debugger, and still get the profiling information .

for others I actually start the VS plugin for the profiler ... this has as advantage that the GC happens automatic, and ("i thought"), the restarting of the application happens faster ("no attach process") ...
I just detected that the plugin does not rebuild the code before starting it,
so if you change some code , and want to detect how this infects the memory usage, you still have to do a manual rebuild FIRST, and then start the profiling ....

This does seem logical now, but I have been using the profiler on and off for 2 months now, and only now detected this.

Any tips on how to improve the speed between 2 profiling sessions,
with changed code ?

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Thu Oct 18, 2007 5:44 pm

How do you start profiling from Visual Studio? If you use the "Start Memory Profiler" command (from the Profiler menu or a context menu), then the project will be built before starting the profiler. Is you use the "Profile Application" command, no projects will be built before profiling.

If you need to debug the application while profiling, you can either start the normal debugger and attach the profiler (as you describe), or you can start the profiler and then attach the debugger. The latter option is the one that I would recommend, since you get more information when the process is started by the profiler (in future versions we will make it easier to debug a profiled process in Visual Studio).

It should not take longer time to perform two profiling sessions, with code changes in between, compared to two similar debugging sessions (unless you make use of Edit and Continue). Are you experiencing that it takes longer than that?
Best regards,

Andreas Suurkuusk
SciTech Software AB

stijn
Posts: 23
Joined: Thu Jun 28, 2007 2:57 pm

Post by stijn » Tue Oct 30, 2007 8:08 am

Must have been doing something wrong then,

adding a message then reprofiling did proof that the code was up to date ...

just had the perception that the building was skipping some steps in the output window

I was perceiving that 2 profiling sessions took much less time then 2 debug sessions, thats why i thought it did not rebuild all projects

Post Reply

Who is online

Users browsing this forum: No registered users and 19 guests