I've written some code that is compiled as a .dll for use a s a plugin in some other software and i'm trying to figure out how or if I can improve the performance of the code.
I've managed to run the performance profiler within VS2017 (output below) but it's pretty difficult to work out what is what. I can see something is using 42% of the time, something else 15%, etc, but I'd like to know what function or line of code is what to see if that time can be reduced. How do I do this in a quick and easy way? Is the string after the dll name an identifier I can use to find out what each one is?
Related
I'm investigating using VS Code for our current C++ project on Linux (using gcc to compile). Though I'm familiar with Visual Studio, Visual Studio Code is a different beast. I'm just trying to get a sample C++ app up in it, but even following this simple tutorial has proved fruitless.
It all falls apart early on. I have a one file program open. When I bring up the command palette, I don't have the "Tasks: Configure Task Runner" task. Since all the following steps depend on this one, I don't know how to proceed.
Was that command removed? Is there a better/more current step-by-step guide? I've heard great things about VS Code and really want to get it working.
[I am very much new to the visual studio environment. After working with visual studio for 2-3 days I was able to get some knowledge about it.]
Well. I am working in a testing team. I just wanna setup a code coverage for cpp code developed in visual studio 2010. There are merely 2 doubts I wanna ask
1.My company has purchased visual studio 2010 ultimate edition and using that I was able to generate the code coverage for a sample test project (.dll) created using Test Project template in visual studio.
The problem here is that developers had written a test project using
cppunit as an .exe. So will I be able to get the code coverage for
an .exe too (with PROFILER enabled) using the usual method to get
the code coverage in visual studio ultimate edition. Or should I ask
them to write the unit tests using the Microsoft's unit test
framework(ie .dll). I just cant simply say do it, I need to present
them the genuine reason to do so.
2.The second thought I had was, there are lot more open source tools to get code coverage for cpp compiled using gcc or g++. So I thought of compiling the cpp code using g++ and use the open source tools to get code coverage. Is this a good idea?
When I shared this idea with a senior developer he said there are lot
more cpp code designed to be MSDN specific, you cant do by this way.If
you wanna do so you should make the code cross platform compatible or
portable[something I couldn't understand].
So here is the final thing, I am trying to present them a immediate solution of getting code coverage using the visual studio ultimate edition which we have. And later on search for the best way to achieve this without purchasing any paid tools like ncover, squish coco, bullseye coverage, etc only so I opted for the above mentioned second option.
My ultimate aim is to display the final report in the Jenkins so that everyone is able to see it without any manual intervention after the build process [which is not possible using the visual studio I guess,].
There is a plugin called MSTestRunner plugin for jenkins which can generate unit tests report but not the coverage report.
I think I made it clear. If this is a duplicate question please mention me the link to.Thanks in advance
I forgot to say this I was also able to find some tool called vcxproj2cmake I think it is clear from the name itself. So if i use this tool to generate a cmake corresponding to the actual vcxproj will i be able to the my second choice?
NOTE:
As for as now, I created a test project (lets say, SampleTestProject) as said in method 1 which has
only one test method (lest say, TestMethod) which in turn triggers all the unit tests written
using cppunit by the below mentioned method.
I asked the devs to make the .exe (which they have already with cppunit unit tests written) as .dll in a specific format like it
should contain a class called TestInitiator which contains the
CppUnit::TextUI::TestRunner (the runner instance which triggers the
cppunit tests, ideally this method should be present in order to trigger cppunit tests) with all the test methods defined in a suite.
This method is called by the above mentioned TestMethod in the SampleTestProject and thereby obtaining the code coverage
By this way the code coverage was obtained with very less change done to the code.Hope you like it!
sometimes I have to debug an application that was written with Borland C++ Builder. This application loads dlls compiled with Visual C++. Is there a debugger that can debug both parts of the application? Currently I have to decide - either I can easily set break points and see the source in Visual Studio or I have to start Borland C++, but I can't work with the source from the Visual-Studio compiled dll.
thank you for your help,
Tobias
You could try OllyDbg - version 1.x does not seem to support the latest Win version but there is also the 2.0 although it's still in alpha state(haven't tried myself that one yet).
EDIT - clarification:
Source debugging OllyDbg reads debugging information in Borland and
Microsoft formats. This information includes source code and names of
functions, labels, global and static variables. Support for dynamical
(stack) variables and structures is very limited.
The above is take from here.
UPDATE:
I'm not familiar with the Borland C++ Builder but at this link you can find some articles explaining how to deal with some interoperability issues between Borland and MS that might be of help.
if both parts built using ulink linker and have debug info you could try cdb32 debugger (from the ulink linker author)
cdb32 is still in its alpha stage though and I personally never tried such "mixed" debugging
Have you tried loading the DLL code in VS, loading the app code in BCB, and having both debuggers attached to the same running process at the same time? Not sure if Windows will allow that, but it might be worth a try.
I suspect there is no perfect answer to your question, you are going to have to compromise in some way, as I'm sure you are already doing.
I have a similar problem to yours at work. The applications that I work on are written in Python instead of Borland C++, but like your situation, these apps rely on a rather large Visual Studio compiled DLL for some functions.
My method of debugging these applications involves a combination of two debugging strategies: the use of an interactive debugger and the so called "printf" debugging technique.
What I basically do is pick one of the two areas as my main debug focus, and that determines my debugging approach:
If for a given situation I decide that I need to debug the DLL with greater detail, then I work with the VS debugger. I set the executable to run in the DLL project as my python script and that enables full debugging of the DLL code. If I need debugging support from the Python side, then I add print statements. If I need a breakpoint on the Python side to inspect some values, I just print all those values and immediately after call a C++ function that does nothing, but that has a breakpoint set in VS.
When I need to concentrate more on the Python side more I use a Python interactive debugger, but I have VS with the DLL project loaded on the side so that I can quickly add any necessary printfs on the DLL and recompile, so essentially the reverse of the above.
I know it's not the answer you expect, but it is a decent solution in my opinion.
It looks that it is possible to convert the debugging information generated by C++ Builder to a format understood by WinDbg (link to discussion). If so you could use it to debug both parts of your application (I haven't tried this though).
you can convert the .map files to Microsoft's debug file format
http://code.google.com/p/map2dbg/
now you can use Windebug; there is also a tool mentioned to convert to pdb format, so you could try the vc++ debugger
I know that VS 2008 Team Edition has a profiler, but I'm also aware of the recent trend they have at Microsoft of completely ignoring unmanaged languages (what's the last time unmanaged C++ got something cool in the IDE?!).. For example I know for a fact that the IDE "Unit Tests" and "Code Metrics" features don't work with unmanaged code.
I tried to google but didn't find any info; so, does anyone know if it works or not?
Yes, it works with native code.
Well I tried it and it does not produce any useful info. For example, in the "Functions" view the source file name is shown as for everything. And yes I am building the release version and have turned on debug info (tried both /Z7 and /Zi). I also tried both Instrumentation and Sampling methods with the same (non) results.
My previous comment last something as stuff in < > was lost. Source files are shown as "Unknown" and I can only see the relative time in each module. This is not a lot of use. How do I get decent output? (Give me TrueTime for VS2008!!)
Coming from a different development environment (Java, mostly) I'm trying to make analogies to habits I'm used to.
I'm working with a C++ project in Visual Studio 2005, the project takes ~10 minutes to compile after changes. It seems odd that if I make a small syntactical error, I need to wait a few good minutes to get a feedback on that from the compiler, when running the entire project build.
Eclipse gave me the habit that if I make some small change I will immediately get a compiler error with an underline showing the error. Seems reasonable enough that VS should be able to do this.
Is this something I can enable in VS or do I need an external plug-in for this?
The feature you are asking for will be available in Visual Studio 2010. Here is a detailed link of the feature details that will be available.
For now, as others have suggested, you can use Visual Assist which can help a little bit.
These are called Squiggles BTW.
You can try the following:
install a plugin like Visual Assist: it will notify you about most of the errors;
if you want to check yourself, use Ctrl-F7 to compile the file you are currently editing - in such case, you will not need to wait for all project to compile. If you are editing a header file, compile one of the .cpp files it is included in.
Yes, C++ is notorious for its build times. Visual Studio cannot perform on-the-fly syntax checking (in case of C++), but you can install Visual Assist to help with that:
(source: wholetomato.com)
10 minutes is quite a long time to wait, are you doing a full build every time? There are a lot of techniques you can use to speed this up, for example using precompiled headers. I try to organise my code so that I do all of my significant changes in the code file instead of the header, then just do a build of that one file (ctrl F7) to check for errors.
You have the "error list window" that will list your errors and warnings after compilation. If you double click on the error it will directly go to the problematic line of code in your source. It's in the menu Display, sub menu "Other windows".
Keep in mind that compiling C++ is a much more difficult task than compiling Java, which explains the increased time.
Visual Assist X is very cool but only detects typos.
It cannot be compiled "on the fly" which explain the feature you ask is not possible. If you have a multicore machine, you can enable parallel building.
Tools -> Options -> Projects and solutions -> Generate and Execute -> maximum number of parallel compilation.
Resharper for C# has it. But for c++, maybe visual assist x ?
Eclipse gave me the habit that if I make some small change I will immediately get a compiler error with an underline showing the error. Seems reasonable enough that VS should be able to do this.
Eclipse has implemented their own Java compiler, and run that in the background every time you type a word to be able to detect and underline errors. I don't know if I'd call that "reasonable". ;)
It's a lot of work to implement that feature, even in a simple language like Java.
In C++, where, as you've discovered, compiles may take minutes, it's harder still.
Visual Studio 2010 is going to implement this feature (again, using a separate compiler, which is much stripped down, and won't always provide correct results -- that's the compromise necessary to ensure that it's fast enough to compile on the fly).