14

I'm compiling a very small Win32 command-line application in VS2010 Release-Mode, with all speed optimizations turned on (not memory optimizations).

This application is designed to serve a single purpose - to perform a single pre-defined complex mathematical operation to find a complex solution to a specific problem. The algorithm is completely functional (confirmed) and it compiles and runs fine in Debug-Mode. However, when I compile in Release-Mode (the algorithm is large enough to make use of the optimizations), Link.exe appears to run endlessly, and the code never finishes linking. It sits at 100% CPU usage, with no changes in memory usage (43,232 K).

My application contains only two classes, both of which are pretty short code files. However, the algorithm comprises 20 or so nested loops with inline function calls from within each layer. Is the linker attempting to run though every possible path through these loops? And if so, why is the Debug-Mode linker not having any problems?

This is a tiny command-line application (2KB exe file), and compiling shouldn't take more than a couple minutes. I've waited 30 minutes so far, with no change. I'm thinking about letting it link overnight, but if it really is trying to run through all possible code paths in the algorithm it could end up linking for decades without a SuperComputer handy.

What do I need to do to get the linker out of this endless cycle? Is it possible for such code to create an infinite link-loop without getting a compiler-error prior to the link cycle?

EDIT:
Jerry Coffin pointed out that I should kill the linker and attempt again. I forgot to mention this in the original post, but I have aborted the build, closed and re-opened VS, and attempted to build multiple times. The issue is consistent, but I haven't changed any linker options as of yet.
EDIT2:
I also neglected to mention the fact that I deleted the "Debug" and "Release" folders and re-built from scratch. Same results.
EDIT3:
I just confirmed that turning off function inlining causes the linker to function normally. The problem is I need function inlining, as this is a very performance-sensitive operataion with a minimal memory footprint. This leads me to ask, why would inlining cause such a problem to occur?
EDIT4:
The output that displays during the unending link cycle:

Link:
  Generating code

EDIT5:
I confirmed that placing all the code into a single CPP file did not resolve the issue.

Ilmari Karonen
  • 49,047
  • 9
  • 93
  • 153
Giffyguy
  • 20,378
  • 34
  • 97
  • 168
  • 6
    It's a problem -- you might as well kill the linker and re-build. Chances are pretty good it'll link normally, but if it runs for a long time like this again, about your only reasonable choice is to try changing linker options until you find some that'll let it link normally. If you can get it to fail reasonably dependably, report the bug to MS. – Jerry Coffin Feb 28 '11 at 06:28
  • 1
    Can you post the relevant code? – ThomasMcLeod Feb 28 '11 at 06:54
  • 1
    Have you tried disabling "Inline Fucntion Expansion" as a test? – ThomasMcLeod Feb 28 '11 at 06:58
  • Does it work without optimiz/sations? – flight Feb 28 '11 at 07:12
  • @ThomasMcLeod unfortunately, I cannot post any actual code. See Edit3 regarding function inlining. @quasiverse I confirmed that function inlining is the culprit. I don't know how to resolve the issue yet, but we might be able to rule-out other optimization changes until further notice. – Giffyguy Feb 28 '11 at 20:05
  • Maybe this is a dumb question, but what does function inlining have to do with the linker? I remember reading that C++ could only inline function calls that were defined in the same compilation unit. This makes me think that the compiler and not the linker should be doing that part. – Samsdram Mar 01 '11 at 05:59
  • @Samsdram The inline function calls are indeed made from the same compilation unit - from within methods of the same class where said functions are defined. – Giffyguy Mar 01 '11 at 06:11

6 Answers6

3

Nested loops only affect the linker in terms of Link Time Code Generation. There's tons of options that determine how this works in detail.

For a start I suggest disabling LTCG alltogether to see if there's some other unusual problem.

If it links fine in Release with LTCG disabled you can experiment with inlining limits, intrinsics and optimization level.

COrthbandt
  • 181
  • 1
  • I'm not entirely clear on disabling LTGC. There is no "Disabled" option in the project settings. I'll have to research that one a little bit. – Giffyguy Mar 01 '11 at 16:53
  • The first place to look at is the "General" section in your project properties. The last item is "Whole Program Optimization". That option allows you to disable LTGC. – COrthbandt Mar 02 '11 at 13:38
  • The next step would be to look at the "Optimization" section that gives you more control options. – COrthbandt Mar 02 '11 at 13:39
  • And finally you can try to refactor and/or restructure your code to move parts into distinct functions and reduce the nesting level. The compiler is pretty smart at things like this so the performance hit should be minimal or not measurable at all. But doing this might change the overall structure just that tiny bit that makes LTCG not hang. – COrthbandt Mar 02 '11 at 13:41
1

Have you done a rebuild? If one of the object files got corrupted, or a .ilk file (though release mode probably isn't using one, I can't be sure about your project settings), then the cleaning pass which rebuild does should cure it.

Closing and re-opening Visual Studio is only helpful in cases when the debugging (or one of the graphical designers) is keeping an open handle to the build product.

Which leads to another suggestion -- check Task Manager and make sure that you don't have a copy of your application still running.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
1

If the linker seems to be the bottle neck and both classes are pretty short, why not put all the code in a single file? Also, there is a multi-processor compilation option in visual studio under C++ general tab in the project settings dialog box. Both of these might help.

Samsdram
  • 1,615
  • 15
  • 18
1

Some selected answers:

Debug builds don't inline. Not at all. This makes it possible to put breakpoints in all functions. It wou

It doesn't really matter whether the linker truly runs an infinite loop, or whether it is evaluating 2^20 different combinations of inline/don't inline. The latter still could take 2^20 seconds. (We know the linker is inlining from the "Generating code" message).

Why are you using LTCG anyway? For such a small project, it's entirely feasible to put everything in one .cpp file. Currently, the compiler is just parsing C++, and not generating any code. That also explains why it doesn't have any problem: there's only a single loop in the compiler, over all lines of source code.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • I confirmed that placing all the code into a single CPP file did not resolve the issue. – Giffyguy Mar 01 '11 at 16:51
  • I'm not entirely clear on disabling LTGC. There is no "Disabled" option in the project settings. I'll have to research that one a little bit. – Giffyguy Mar 01 '11 at 16:52
1

Here in my company we discovered something similar.

As far as I know it is no endless loop, just a very long operation.

This means you have to options:

  1. turn off the optimizations
  2. wait until the linker has finished

You have to decide if you really need these optimizations. Here the program is just a little helper, where it does not matter if the program is running 23.4 seconds or 26.8. The gain of program speed compared to the build speed are making the optimizations nearly useless. At least in our special scenario.

ConfusedSushi
  • 874
  • 8
  • 16
  • I agree that the performance benefits do not outweigh the price of a week-long compile-time. However, I believe it is worth some of my time and energy to attempt to resolve the linker issue without disabling the optimizations. – Giffyguy Mar 01 '11 at 16:49
  • Today I recognized, premature pessimistic can also cause this linker behavior. When I was reviewing a program I found a lot (hundreds?) of stuff like func(string arg), there it was totally unnecessary. Thats why I replaced it with stuff like func(const string& arg). I gain a linker speedup by approx. 20%. – ConfusedSushi Sep 24 '12 at 12:21
0

I encountered exactly this problem trying to build OSMesa x64 Release mode. My contribution to this discussion is that after letting the linker run overnight, it did complete properly.

Perry Kivolowitz
  • 16
  • 1