Using Visual Studio 2015 diagnostic tool to examine memory usage - windows

So VS2015 has a cool new Diagnostic tool which shows memory and CPU usage while debugging, which should be very useful. However I'm having some confusion while using it.
I'm writing a Windows 8.1 XAML app, started with a blank template, I just hit F5 and the Diagnostic tool showed memory usage of 25MB (Process memory), so far so good.
After I started playing around with the code a bit (just some setups, no business logic, no networking, no images yet), I ran the code again and this time the tool showed memory usage of 35MB, which scared me a bit. So I tried running the profiling tool and it showed only about 50KB in the managed heap.
To add to the confusion, when I checked with the Task manager, it showed that my process was taking up only 16MB]2
What can be an explanation to all this and what figure should I believe in?

Related

visual studio xaml editor lag

I am experiencing a huge amount of lag while using Visual Studio (2019, 2022) xaml editor. So much lag that the editor is frustratingly unusable. Visual studio itself is not slow, so none of the "improve performance" articles that I can find are relevant as general performance is good. This problem really only manifests in the xaml editor.
I believe this might be related to how the Motherboard/CPU is configured (perhaps to use energy saving features so as to consume less energy). However I have no evidence to really prove this, just a gut feel as when using the xaml editor, I hear the CPU fan spin up and I can see activity on task manager showing 6 cores in use, and clock speed increases from its base of 4Ghz to around 4.35Ghz.
I also conclude this because I only experience this problem on one machine, which is a new build with an AMD Ryzen 9 5900X 12 Core cpu. The older machine that works fine has an intel i5-6600K 4 core CPU running at 3.5Ghz. When editing on the old machine, the experience is normal and fine, but with the AMD cpu machine, the visual studio xaml editor is just unusable.
Even a simple action such as just trying to select a few lines of xaml (shift + up cursor to select a few lines), produces lag, and I can hear the fan spin faster, see the CPU speed rise, and if I keep doing it, the cursor is jumping around all over the place and I end up typing in the wrong place, etc, etc.
The new machine has a completely clean/fresh windows build with developer tools. Both bios configurations are reasonably vanilla, despite both CPUs being the unlocked versions, I don't (well not in this circumstance) use any form of overclocking. Also, Visual studio installations are pretty standard, with no customisations.
I have been through the bios (ASUS ROG STRIX B550-F motherboard) and there is nothing obvious that I can see would be causing this - all the settings are on their defaults. I also tried the xaml options within visual studio, but they made no difference and I need to use the XAML designer so disabling it is not an option.
However I assume there are either features in the bios that I could alter? Or perhaps there are other software options in visual studio that might change this behaviour?
Any thoughts or suggestions on what to look at much appreciated.

Wall clock analysis from Visual Studio Diagnostics Hub

The Performance and Diagnostics Hub in Visual Studio is an amazing feature. I use it for diagnosing Memory and high cpu issues while writing code. However, so far I am not able to figure out how to use this tool for troubleshooting low-cpu hang scenarios (or wall-clock analysis). Let's say my application takes long time on waiting a response back from a network or file I/O. Is there anyway of determining this from the Diagnostics windows in Visual Studio during a debugging sessions? I was hoping this analysis could be part of CPU Analysis section in there.
Like this blog here:
https://blogs.msdn.microsoft.com/devops/2014/02/28/new-cpu-usage-tool-in-the-performance-and-diagnostics-hub-in-visual-studio-2013/
The CPU Usage tool measures the CPU’s resources in terms of how much time each core in the CPU spends executing your code, it seems that it didn't provide the feature to resolve/collect the low-cpu hang issue.
Maybe you could think about using other tool like the PerfView or the suggestion of magicandre1981.
https://blogs.msdn.microsoft.com/vancem/2012/11/26/wall-clock-time-analysis-using-perfview/

How can I profile the memory usage in a wp7.1 background agent?

I'm working on a scheduled background agent for Mango (7.1)
I've managed to cut my memory usage down from 10.5MB to 6.5MB using manual trace techniques based on DeviceStatus.ApplicationPeakMemoryUsage along with some intelligent guesswork about what to optimise.
However, now I need to get down to below 6MB - and the final 0.5MB is proving elusive.
I've managed to run the "Windows Phone Performance Analysis" tool on the main app, but can't seem to find a way to get it to run against the agent.
Are there any tools and/or techniques available to assist me in working out what is filling up my agent's memory? Ideally I'd like a way to investigate the entire memory space - including both code and data, and ideally it should work against a release build.
As has already been said, the debugger will add a non-negligible memory overhead. So the best way I found is:
Activate the emulator's console: http://nicksnettravels.builttoroam.com/post/2011/01/19/Windows-Phone-7-Console-Window-on-64-bit-machine.aspx
At strategic points of your code (beginning and end of the main functions for example, or after allocating a big object), display the memory consumption:
Console.WriteLine("Function {0}: {1}", "name of your function", DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage"));
Start the application without attaching the debugger (Ctrl + F5), sit back and enjoy
Remember if you are running the background agent in Debug mode this adds about 2MB onto the memory footprint of the agent, so you might be OK.
You could probably use the ApplicationPeakMemoryUsage still and write the memory details out to a file in Isolated Storage when running the app directly, rather than from Visual Studio.
HTH - Rupert.
You may find the following blog post interesting, you may have already seen it but it describes both the debug memory addition as well as some tips to decrease the memory footprint.
http://www.pitorque.de/MisterGoodcat/post/Windows-Phone-Background-Agents-Pitfalls-(2-of-n).aspx

How do I find out what Visual Studio extension is causing memory leaks?

My Visual Studio (2010 SP1) has a serious memory leak, and it seems to be caused by one or more of the installed extensions.
I have tried to narrow it down by turning extensions and add-ons on and off, but it takes a while of work to build up a significant leak and the results aren't totally conclusive. It rarely takes more than a few hours before the devenv.exe process uses 2GB memory and starts trashing, which is becoming a bit of a pain to work with.
Is there some way to make VS emit information on memory allocated for extensions?
Are managed extensions running in their own AppDomain? Maybe that would allow me to turn on some performance counters that could help pinpoint the problem.
Anything else I can do to troubleshoot this apart from disabling stuff one by one until the problem disappears?
According to the JetBrains faq page you should be able to attach to an already running process when it starts to display memory leak issues. Perhaps you can give that a shot. Note that the faq states that you need to be using version 5.

Windows Phone Memory Profilers

I'm currently having a hard time driving down the peak memory consumption of my background agent below the 6MB limit. Are there any recommendations for WP7 capable memory profilers. I am not even asking for something along the lines of dotTrace but basically anything that offers some insight about what's going on.
The Windows Phone SDK comes with a profiler for both memory consumption, and other things, that's available in Visual Studio after installation of the SDK.
You can read more about it on MSDN
Also, try look isolated at the background agent code, and move it to a separate application, where you run it in the foreground. That could possible make it easier for you to nail where the problem is.

Resources