views:

50

answers:

2

Hello!

When building projects in Visual Studio (I'm using 2008 SP1) there is an optimizing option called Enable link-time code generation. As far as I understand, this allows specific inlining techniques to be used and that sounds pretty cool.

Still, using this option dramatically increases the size of static libraries built. In my case it was something like 40 mb -> 250 mb and, obviously building process can become REALLY slow if you have even 5-6 libraries that are that huge.

So my question is - is it worth it?. Is the effect of link-time code generation measurable so that I leave it turned on and suffer from slooooooooooooow builds?

Thank you.

+2  A: 

How are we supposed to know? You're the one suffering the slower link times. If you can live with the slower builds, then it speeds up your code, which is good.

If you want faster builds, you lose out on optimizations, making your code run slower.

Is it worth it? That depends on you and nothing else. How patient are you? How long can you wait for a build?

It can significantly speed up your code though. If you need the speed, it is a very valuable optimization.

jalf
Well, I am actually seeking for an answer from somebody who (probably, there is someone :) profiled and if link-time code generation actually has no performance effect in, for example, 99% cases, why not simply turn it off?
HardCoder1986
Okay, the last sentence is what I was seeking for....
HardCoder1986
@HardCoder1996: one very simple thing, during development, compile in debug (no optimization) and during automated tests and for delivery, compile with full optimizations. This way you have fast compiles for developping and fast binaries for your clients.
Matthieu M.
+2  A: 

It's up to you. This is rather a subjective question. Here's a few things to go over to help you make that determination:

  1. Benchmark the performance with and without this feature. Sometimes smaller code runs faster, sometimes more inlining works. It's not always so clear cut and dry.
  2. Is performance critical? Will your client reject your application with it's current speed unless you find a way to improve things on that front?
  3. How slow is acceptable in the build process? Do you have to keep this on while you, yourself build it, or can you push it off to the test environment/continuous build machine?

Personally, I'd go with whatever helped me develop faster and then worry about the optimizations later. Make sure that it does what it needs to do first.

wheaties