I'm looking for a free code profiler (performance profiler, not a memory profiler) which works for VSTO applications (specifically Excel in my case, but I gather that if it works for one, it should work for all).
I have tried Eqatec Profiler, but it can't seem to launch the application from the profiler (The Run app button is greyed out, which I'm gathering is because the VSTO application is compiled into a dll which runs in-process with Excel.exe).
If anyone has successfully used Eqatec or another free code profiler to profile a VSTO application, I'd be interested to hear how you did it.
What you're doing should be possible with EQATEC Profiler.
When you're simply instrumenting one or more DLLs then there is no distinct "application to run": you simply have some instrumented DLLs, but the profiler doesn't know in what way you intend to use them.
However, the instrumented assemblies are (along with the runtime-module, EQATEC.Profiler.RuntimeFullNet.dll) always completely "self-contained", meaning that they perform the timing themselves as soon as the methods within them are used. So you simply need to have your VSTO app load the DLL as usual and voila, the DLL will itself start accumulating timing information and start listening for a connection from the profiler with which you can then take snapshots etc.
So to summarize:
Build you DLL and keep the profiler running
Have your VSTO app load the DLL (however you do that)
The profiler and instrumented DLL should now be connected (see the Run-tab)
From within the profiler you can now take snapshots
I hope this helps. If not then let me know.
Have you tried Microsoft's CLR Profiler?
Check out How To: Use CLR Profiler at http://msdn.microsoft.com/en-us/library/ms979205.aspx.
Download CLR Profiler for the .NET Framework 2.0 is available at https://github.com/MicrosoftArchive/clrprofiler.
I have used it with great success many times.
Related
We are developing a PC application that runs on Windows.
What would be a good approach for the developers to get some kind of load testing done before it goes to Test? -
Using an already existing tool for GUI testing like Selenium? Any other easy to use tool? Our code is in C++ (Open GL) on Windows.
Add a test stub within our code to simulate a load of the events that would get generated every time a button is clicked.
Use of a run time memory leak tool like Purify Plus or drmemory
We are developers and are primarily looking at some bare minimum load tests before the test team runs extensive tests.
Is a combination of #2 and #3 or just #3 helpful for this?
Please let me know if you have any other comments..
So you typically don't load test desktop applications unless that application is making calls to your server (in that case you would be load testing the sever).
I've never seen a desktop application which isn't able to handle user load on a single desktop. Unless you are querying a db on the user's desktop and need to worry about loading a massive amount of data and pegging the CPU, you should be fine.
When programming in C/C++, I've found GNU gprof invaluable in building a program which successfully utilizes the CPU's cache. GNU gprof is really invaluable beacuse it will provide you with the flat profile tool, which will give you the total execution time spent in each function and its percentage of the total running time, along with function call counts.
For UI desktop application testing, these two tools are really great and have been recommended by Joel (from Joel on Software):
TestComplete
Sikuli
You can learn more about about GNU gprof here.
Both Silk Performer and Load Runner offer GUI load testing support. I've used both and have ran up to 250 Virtual User loads which have simulated a few thousand users per/day. I've sometimes have run into applications where all protocol level load testing tools don't support the applications and the GUI approach works great. I've also been learning to Selenium with JMeter to run the GUI load tests but getting the selenium script to be reliable has been very difficult. If you run into application that don't need huge amounts of users you'll find the GUI approach to be much faster and sometime more accurate than the protocol based approach.
Any good place to learn about POST and how to design and code one? I am a C++ programmer and quite baffeled with the term.
Thanks
You might want to take a look at the code for coreboot, a free software (open source) BIOS project that runs on many different kinds of hardware.
You can checkout the OpenBIOS project.
They have information on numberous opensource bios/firmware implementations.
Being open source you can grab the code from svn or read it online for all of them.
BIOS? That's not too common in the embedded world, the one place where people still write POSTs. Typically, they happen before the OS itself starts, or alternatively, as the OS starts.
The goal is to figure out whether the device can run, run in degraded mode, or should signal malfunction. A typical sequence is test CPU and XIP flash, then memory, fixed hardware, and then optional hardware. You define a series of tests. A test has a start function and a check function. The start functions kicks off the test; the check polls to see if a result is already available. Tests have dependencies, and the test controller starts those tests for which the dependencies have passed (CPU and RAM being the special cases, if they're broken it's not feasible to have a nice test controller).
As you can infer from the CPU and RAM tests, you don't have the luxury of C++. You can't even assume you can use all of C. During the first part of the POST, you might not even have a stack (!)
Open source EFI BIOS, with documentation and specs (good way to learn):
https://www.tianocore.org/
Background In June of 2004 Intel
announced that it would release the
"Foundation Code" of its next
generation firmware technology - a
successor to the PC BIOS - under an
open source license later in the year.
The Foundation Code, developed by
Intel as part of a project code named
Tiano, is Intel's "preferred
implementation" of the Extensible
Firmware Interface (EFI)
Specification. The code to be released
includes the core of the Foundation
Code as well as a driver development
kit. To follow through with its
intentions to release the code as open
source, Intel partnered with
Collabnet, an industry leader in
providing tools and services to
support an open source initiative, to
create a community for this effort.
The result of this partnership is this
Open Source Website.
Since there are more projects that are
EFI-based working in parallel with the
Foundation Code, it was decided to
release the EFI Shell Application and
the EFI Self Certification Test (SCT)
project to the open source community.
POST (Power On Self Test) is part of the Bios, and writing a POST, but not other parts of the BIOS, seems like an odd task indeed.
The documentation section of the processor manufacturer's web site would be a good start for BIOS programming. I remember writing an 80186 BIOS and POST a long time ago, and I worked exclusively with the Intel specs.
And btw, you will be doing this in Assembler, not C++.
How do you debug lua code embedded in a c++ application?
From what I gather, either I need to buy a special IDE and link in their special lua runtime (ugh). Or I need to build a debug console in to the game engine, using the lua debug API calls.
I am leaning toward writing my own debug console, but it seems like a lot of work. Time that I could better spend polishing the other portions of the game.
There are several tools floating around that can do at least parts of what you want. I have seen references to a VS plugin, there is a SciTE debugger extension in Lua for Windows, and there is the Kepler project's RemDebug, as well as their LuaEclipse.
RemDebug may be on the track of what you need, as it was built to allow for debugging CGI scripts written in Lua. It does require access to the LuaSocket module to provide a communications channel between the target script and a controller as well as a couple of other modules.
A bigger issue might be the ability to load arbitrary modules from within whatever sandbox the game engine has put around your scripts. If you have some control over the engine, then that won't be as big an issue.
This isn't currently possible for developers of Adobe Lightroom plugins, for example, because Lightroom does not expose require inside the plugin's sandbox.
A surprise to me has been how rarely I have felt a need for a debugger when working with Lua. I've built several small applications in it for various projects and have been surprised at how well a combination of complete stack backtraces and the occasional print call works to locate the bugs that require "strict" didn't prevent in the first place.
How about Decoda?? there is a video that explains how to use it, and it works pretty darn well for embedded lua source. (i am a happy customer). and it's pretty cheap.
You don't need to write your own console as you may want to start with one of the existing ones. RemDebug has already been suggested; I have been developing MobDebug, which is a debugger based on RemDebug, but with a host of new features and bug fixes. The detailed list of the changes is in the README.
Enabling debugging in your script may be as simple as adding require('mobdebug').start() (if you are running your app and the debugger server on the same machine). This should try to connect to the debugger listening on a default port on localhost. You can use a command-line interface included in MobDebug, or you can use a ZeroBrane Studio, which is a Lua IDE that integrates with MobDebug to provide debugging capabilities. The IDE supports debugging for Love2d, Moai, and other Lua engines and may well work for your set up too.
You can use my debugger: GRLD (graphical remote lua debugger). Like RemDebug it uses a socket connection, but unlike RemDebug it has a nice graphical interface. The source code is provided, so you can make it work on any platform. It works with the standard lua runtime. Free of charge for non-commercial use.
EDIT: sorry, I had to close the website, so the software is not available for download anymore. I might release it as open source software later, if I ever find the time.
EDIT 2: link updated, now hosted in github under the MIT license (open source)
I don't see how calling DebuggerBreak should work, since that is .NET specific. I would assume that only works with the forked Lua targeting the CLR.
If you are using standard Lua you have some rudementary debugging facilities through the lua function call debug.debug(). That will throw Lua into your console, so if you are running lua from a console, you should be able issue lua commands interactively to inspect your current state. debug.debug() wont put you into the current stack frame, so you have to use debug.getlocal() to read the values of your variables.
I haven't tried it myself yet, but I actually don't think making your own workable debug console is that much work. Remember Lua is not as complicated language as C++, so doing this is a lot easier than making a real C++ debugger like say gdb.
I think there are a lot of people who have done similar things already, whos code you could look at. Here is CLI debugger written in only lua. Just one lua file. Shouldn't be to hard use and modify for your needs.
If you are using windows and VS - Can you use the trick we use?
Copy the lua code in a file. Then in the lua code make a call to the Debugger api (in C++ this is DebuggerBreak() I think - see here). then when the lua code executes the debugger will fire up and you should be able to specify the file. Then debug as normal?
I am looking for a performance profiler that is able to profile a C++ library that is being called from a .NET Application.
I tried Purify+ without success (I don't get the calls the COM library) and a few others.
AQTime
Have you tried the IBM or AMD tools? They're really low level (being made from processor makers!) and so maybe they can profile your component.
Here is a thread that may be of use for you:
Decent profiler for Windows?
xperf might be good.
I know that at a previous job my group used vtune successfully.
Background: I'm currently debugging an application written over a custom-built GUI framework in C++. I've managed to pin down most bugs, but the bugs I'm having the most trouble with tend to have a common theme.
All of them seem to be to do with the screen refreshing, redrawing or updating to match provided data. This is a pain to debug, because I can't break on every refresh, and most of this stuff is time-sensitive, so breakpoints occasionally "fix" the bug.
Q: Does anyone have any tips for debugging Windows-based GUIs, especially regarding the refreshing of individual components?
I agree with dual monitors or even remote debugging to reduce interfering with the messages.
I also highly recommend Spy utilities. These let you see what messages are being sent in the system. One such program is Winspector.
http://www.windows-spy.com/
This may not help, but I've found using dual monitors useful in this scenario. I have the debugger on one screen and the application on another. I can then step thru the code and see the application refreshing or doing whatever it is on the other screen.
There is still issues with focus doing this way, but at least I can see when it repaints.
Logging is pretty much the only answer. Without knowing your framework I can't give an exact answer but basically open a file and append messages in the various procedures of interest. Finally close it.
In the message include the values of the variable that you are interested in.
Also using the window Message Box is useful to see if you are in the correct branch or procedure. This has minimal effect on over all flow.
Finally try downloading any of the express version of .NET and use Winforms to try to make test of particularly problematical areas. While Winform is it own framework there is a high degree of correspondence between it's control and the ones provided by Windows.
I maintain a simulation of the Project Mercury Capsule as an add-on for the Orbiter Space Simulator. It is written in C++ and has to use Win32 directly for some of the panels and dialogs. There were times I fired up VB6 (VB.NET later) to work out some complex interaction and then translated it over to it's Win32 equivalent in C++.
However this is a last resort.
Having a dual screen really help when debugging refresh/redraw problem for Windows controls and UI.
Having the application on the second screen will not have the debugger generate "invalidate" on the main UI screens when it breaks for a debugging breakpoint.
If you cannot have a second screen, try to have both application side-by-side so that the application and the debugger will not interfere.