Where does my Application need redesigning and Speeding Up?

[wavering]

Firstly, I am using Visual Express 2013

I have a project (converted from VB6 and VC++ 6.0) that is very time intensive - it may run for hours or even weeks looking for a solution.

Currently, it structures a solution in vb.net and then passes it to native code in vc++ for evaluation. I find that it is now running at half the speed it used to run before conversion.

This suggests that it is spending a lot of time in vb.net (since the native code in vc++ is essentially the same as it always was)

Clearly, I need to know how much time it spends in every single function or subroutine (of which there are hundreds) in BOTH vb.net and vc++. Then I may well convert some of the vb.net routines into vc++ native code. Ultimately, I suspect that I will just use vb.net for all of the endless boring, non time critical stuff so that once it starts actively running it uses only vc++ native code ...

Because I am running2013 Express there is no Analyze Menu. So, what is the best way to do this (ideally, I wish to avoid upgrading Visual Studio)?

Are there any good 3rd party applications that can do this? All suggestions much appreciated ...

[Arjay]

(ideally, I wish to avoid upgrading Visual Studio)?

That's too bad - Visual Studio 2015 is going to have a killer built-in profiler.

[VladimirF]

Third-party profilers might cost you more than a Studio upgrade.
There is no substitute to a profiler.

Given your limitations, I see two options:
1. Manual profiling. In your outermost function, place a few time markers / counters, see which part takes the longest, repeat. Divide and concur!
2. Outsource your profiling to an experienced and reputable volunteer, possibly with NDA. You can find one here

[moffy]

Download Visual Studio 2013 Community Edition, it is the same as Visual Studio 2013 Professional.

[OReubens]

If your code takes "weeks", then it should be fairly Obvious where the bulk of the time is going to. You don't even need a profiler. A simple run through a debugger should give you the "this is the problem" area quite quickly.

Note also that even WITH a profiler, you're unlikely to solve this issue significantly by approaching this with a profiler which is typiocally oriented towards "spot optimizing", wheraes for this order of optimization, you'll need a complete redesign/different approach to the problem.

Also, if you're dealing with an inherently exponential time problem (or linear with massive data sets), then no matter the approach you can't solve it, though you might be able to devise "adequate" solutions in a "reasonable amount of time".

a rewrite from VB to C++ should get you some extra speed, but not of the kind that will turn a runtime of weeks into minutes/hours. A change like that needs an algorithmic rewrite.


P.S. as I said before in these forums, profilers are nice tools, but there aren't a whole lot of people out there that know how to use them effectively.


other than that, changing from .NET to a native solution, yes, 50% is a fairly reasonable performance improvement, especially if your code does a lot of memory management (which is slow er in .NET due to the garbage collection overhead).

[wavering]

Firstly, many thanks for the detailed reply. Since posting the original question I have found some bugs and it is now running at comparable speed to the original vb6/vc++ 6.0 version BUT it would still be nice to actually analyse and find any bottlenecks

If your code takes "weeks", then it should be fairly Obvious where the bulk of the time is going to.

It can take from less than a second to a few weeks to find an optimal solution. In the course of this it goes through dozens of routines - some in vb.net, some in vc++ and some in asm (for complex bit handling - not speed). Basically, it goes in big circle through a whole series of routes - right at tha heart is a routine that calls itself to multiple depths. It takes a few hours to go round a trillion times (ie 10 ^ 12)

You don't even need a profiler. A simple run through a debugger should give you the "this is the problem" area quite quickly.

Unfortunately not - I used a profiler in vb6 some years back and was VERY surprised at where the bottlenecks were. I now need to do the same again in Visual Studio - hence the question!

Note also that even WITH a profiler, you're unlikely to solve this issue significantly by approaching this with a profiler which is typiocally oriented towards "spot optimizing"

I need to know where it spends its time eg

Routine 1 2%
Routine 2 51%
Routine 3 1%
Routine 4 2%
Routine 5 2%
....

wheraes for this order of optimization, you'll need a complete redesign/different approach to the problem. Also, if you're dealing with an inherently exponential time problem (or linear with massive data sets), then no matter the approach you can't solve it, though you might be able to devise "adequate" solutions in a "reasonable amount of time".

Agreed

a rewrite from VB to C++ should get you some extra speed, but not of the kind that will turn a runtime of weeks into minutes/hours

Agreed, but if it is say, spending 5% of its time in vb.net than no need to bother. If it is 80% then could maybe turn 24 hours into 12 hours

A change like that needs an algorithmic rewrite.

Agreed

P.S. as I said before in these forums, profilers are nice tools, but there aren't a whole lot of people out there that know how to use them effectively

Well, I can try, maybe ...

other than that, changing from .NET to a native solution, yes, 50% is a fairly reasonable performance improvement, especially if your code does a lot of memory management (which is slow er in .NET due to the garbage collection overhead).

Yes, that is what I need!

[OReubens]

It can take from less than a second to a few weeks to find an optimal solution. In the course of this it goes through dozens of routines - some in vb.net, some in vc++ and some in asm (for complex bit handling - not speed). Basically, it goes in big circle through a whole series of routes - right at tha heart is a routine that calls itself to multiple depths. It takes a few hours to go round a trillion times (ie 10 ^ 12)

There's no way around the fact that 10^12 times round a loop will take time. At these amounts, even a single µs per loop will end up taking 10^6 seconds (or just over 11 days).

If inside that loop you are doing native to managed mode transitions (which the assembly seems to indicate), then that alone is already going to be a significant part of the time taken.

Tip: remove the assembly, you're probably LOOSING performance because of the call and return overhead, rather than doing it 'inline' in the code. The C++ compiler can handle most bit twiddling operations more efficiently than you can do them with a call overhead, the only exception are the rotates and rotate through carry which the compiler never uses (other than inline intrinsics). Even in that case, calling a function for a single rotate in assembly is going to be slower than doing it "the C++ way".

Unfortunately not - I used a profiler in vb6 some years back and was VERY surprised at where the bottlenecks were. I now need to do the same again in Visual Studio - hence the question!

the bottleneck is 10^12 times round the loop. The ideal approach would be to find ways to reduce the amount of times you go through the loop.
the stuff inside there is not technically a "bottleneck". sure you could shave off a bit here and there which will make a noticable impact simply due to the 10^12 loops, but at heart, it's a wrong approach and you're already into end-level optimisations when you should focus on reducing the loop count and get a bigger impact type result.

Agreed, but if it is say, spending 5% of its time in vb.net than no need to bother. If it is 80% then could maybe turn 24 hours into 12 hours

Getting a profile capable build going and getting the profiler to spit out some basic output is easy enough. It's explained in detail in the VS help if you use that one. Or it should be explained in your profiler manual/help otherwise.

Making actual sense of the output and knowing how to spot the real problem areas is a bit of an obscure science. Depending on the technology used by the profiler (the VS profiler uses trigger points), you could be sidetracked entirely if you don't know how to spot the "this doesn't make sense" type anomalies.
Some profilers use runtime code hotspots, others insert entry/exit code in designated (or even all) functions, ... There's different ways a profiler can use to determine where time is going. the all have their pro's and cons and problem areas.

I don't use the VS profiler myself, have tried it in the past but found it to be not to my liking. THe new VSTS has supposedly been improved a lot, but I haven't tried it out. I'm pretty much sold on vtune myself, it's has a learning curve, but it's quite excellent and the outputs are clear and very rarely anomalous.