I am trying to profile and instrument my VSTO Excel plug-in using Visual Studio 2012 on Windows 8. I would like to collect managed function call counts and their timings.
I have no problems with the default sampling option, but the results are generally too high level for me (i.e. ntdll.dll and wow64.dll are the binaries doing "all the work"). However, my attempts to instrument the plug-in always yield "no data" results; I've tried to attach to an existing Excel process, pause and switch the profiling method to "Instrumentation", as well as using the Performance Wizard to create an instrumented profile.
In this case, the output window shows messages like the following:
Data written to C:\project-source\Report130912(3).vsp.
Profiling finished.
File contains no data buffers
File contains no data buffers
Analysis failed
Is this scenario supported for Visual Studio, or have I done something wrong? Is there another tool I can try to obtain this data?
I figured this out by... making my search query more general :)
http://mikedoszhang.blogspot.com/2011/10/profile-net-office-add-in-through.html
In essence, each binary that requires instrumentation must be registered for COM interop and built for the x86 architecture (not Any CPU). Also, you need to explicitly specify the binaries that you want to instrument.
Related
In .NET6 I want to retrieve the native handle (NOT the "Managed Thread ID") of the OS thread, on which the handle-retrieving function just runs, as a (possibly casted to) UInt32.
I found a solution for Windows (using the kernel's "GetCurrentWin32ThreadId"), but I want to have solutions also for Linux, MacOS and Android, assuming that the respective implicit OS' object models contain also "Thread Handles".
To avoid senseless reading time consuming tries to lead me on other paths: my question is very precise, please don't ask "why"s! And please avoid "you could try"s, because I don't have access to Linux-Computers, Macs, Smartphones, and don't want to bother others by intermediate tests and/or even "tries". I need concrete definitoric "code snippet" answers.
I need it 1. for debugging purposes, 2. for .NET-ManagedThreadPool monitoring (if it always works correctly), 3. cross-checking with the Visual Studio output (about finished threads) and 4. some other (also platform specific to be handled, native) functions/stuff (e.g. native thread coordination, cross-process).
My goal:
I want to deliver my program(s) [atm especially the "OpenSimulator"-software, including the server (Windows, Linux) as well as the user's viewer (Windows, Linux, MacOS, iOS)] with a target-platform-independent .NET6-".exe", and an OS-respective target-platform-specific .NET6-.dll as the respective implementation for certain interfaces, to bridge the yet current compatibility-gaps, something/somehow like MAUI tries to do, but generalized more complete on the logical (.NET6) layer.
I had noted a new tab 'Captures' on the left side of the Android Studio 2.3.3.
For me it is seem to be empty.
What is Captures meant for?
Please refer the documentation explaining on Captures in Android Studio.
When you're monitoring memory usage in the Memory Monitor included in Android Monitor you can, at the same time, dump a snapshot of the Java heap to an Android-specific Heap/CPU Profiling (HPROF) file. The HPROF Viewer displays classes, instances of each class, and a reference tree to help you track memory usage and find memory leaks. HPROF is a binary heap dump format originally supported by J2SE.
After you do a heap dump, Android Studio automatically stores it so you can view it again. "Captures" is where you see these saved HPROF dumps.
You can also see captured view layout etc there as well.
There isn't an answer to this in the built-in help. However, according to the release notes from 2015, it is a "view which shows the various performance data files you've collected".
You can learn more about Captures in the documentation about HPROF.
Once a project has been profiled in instrumentation mode and the various portable and platform events from the CPU counters menu have been selected where should they be visible?
In the profile report all the basic performance data is visible (cpu time, calls, etc...) however but not the selected CPU counters.
They are not present in the Marks section either. There are only Windows counters, regardless of whether they were enabled or selected.
The CPU counters appear in the Functions view of the profiling report. In order for them to be collected you must run Visual Studio as administrator. There is a warning in the output window if you do not do this.
In a huge C++ builder 2010 application with several DLL's being built and linked etc. What would be the best way to trace down memory leaks that accumulate over a long period of time? Say that the application has to be running for a week or something on the target machine before it becomes an issue. Let's assume that there is no profiling application available like AQ Time or something similar. Just using the standard IDE and perhaps some code.
My initial idea was to write a macro to use in all classes that keeps track of the number of instances and space used of each class type to start with.
The RTL uses FastMM as its memory manager. FastMM supports memory leak reporting and tracing. The native version of FastMM that is included in the RTL is a stripped down version, but it does support minimal leak reporting. You can set the RTL's global ReportMemoryLeaksOnShutdown variable to true at run-time and FastMM will generate a basic leak report when the app is closed. For more advanced usage, you can download the full version of FastMM and add it to your app, which will replace the RTL's native version. You can then configure FastMM as desired.
Environment
Windows XP SP3 x32
Visual Studio 2005 Standard Edition
Honeywell Dolphin 9500 Pocket PC/Windows Mobile 2003 Platform
Using the provided Honeywell Dolphin 9500 VS2005 SDK
.NET Framework 1.1 and .NET Compact Framework 1.0 SP3
Using VC#
Problem
When I save an image from the built in camera and Honeywell SDK ImageControl to the device's storage card or internal memory, it takes 6 - 7 seconds.
I am currently saving the image as a PNG but have the option of a BMP or JPG as well.
Relevant lines in the code: 144-184 and 222, specifically 162,163 and 222.
Goal
I would like to reduce that time down to something like 2 or 3 seconds, and even less if possible.
As a secondary goal, I am looking for a profiling suite for Pocket PC 2003 devices specifically supporting the .NET Compact Framework Version 1.0. Ideally free but an unfettered short tutorial would work as well.
Things I Have Tried
I looked into asynchronous I/O via System.Threading a little bit but I do not have the experience to know whether this is a good idea, nor exactly how to implement threading for a single operation.
With threading implemented as it is in the code below, there seems to be a trivial speed increase of maybe a second or less. However, something on the next Form requires the image, possibly in the act of being saved, and I do not know how to mitigate the wait or handle that scenario at all, really.
EDIT: Changing the save format from PNG to BMP or JPG, with the threading, seems to reduce the save time considerably..
Code
http://friendpaste.com/3J1d5acHO3lTlDNTz7LQzB
Let me know if the code should just be posted here in code tags. It is a little long (~226 lines) so I went ahead and friendpasted it as that seemed to be acceptable in my last post.
By changing the save format from PNG to BMP and including the Threading code shown in the Code link, I was able to reduce the save time to ~1 second.
You're at the mercy of the Honeywell SDK for this one, since their control is doing the actual saving of the image. Calling this on a separate thread (i.e. not the UI thread) isn't going to help at all (as you've found out), and it will actually make things more difficult for you since you need to wait until the save task is completed before moving on to the next form.
The only suggestion I can make is to make sure you're saving the image to internal memory (and not to the SD card), since writing to an SD card usually takes significantly longer than writing to memory. Or see if you can get technical support from Honeywell - 6-7 seconds seems way too long for a task like this.
Or see if the Honeywell SDK lets you get the image as a byte array (instead of saving to disk). If this call returns in less than 6-7 seconds, you can handle persisting it yourself.