CODEWITHSUNDEEP
c++performancevisual-c++compiler-constructioninline
sharptooth
sharptooth

Reputation: 170499

What happens if function inlining is too aggressive?

Each time I read about inline keyword in C++ there's a long explanation that the compiler makes a "speed versus code volume" analysis and then decided whether to inline a function call in each specific case.

Now Visual C++ 9 has a __forceinline keyword that seems to make the compiler inline the call to the function unless such inlining is absolutely impossible (like a call is virtual).

Suppose I look through some project without understanding what goes inside it and decide myself that one third of functions are small enough and good for inlining and mark them with __forceinline and the compiler does inline them and now the executable has become say one hundred times bigger.

Will it really matter? What effect should I expect from having functions inlined overly aggressively and having one hundred times bigger executable?

Upvotes: 5

Views: 997

Answers (6)

B. D
B. D

Reputation: 7798

This is somewhat a complex topic, and I think you should have a look at this C++ faq lite about inline

It explains that there is no simple solution, and there are many things to consider (but it all boils down to a good intuition anyway!)

Upvotes: 1

MSalters
MSalters

Reputation: 179819

Others have already mentioned the impact on cache. There's another penalty to pay. Modern CPU's are quite fast, but at a price. They have deep pipelines of instructions being processed. To keep these pipelines filled even in the presence of conditional branches, fast CPUs use branch prediction. They record how often a branch was taken and use that to predict whether a branch will be taken in the future.

Obviously, this history takes memory, and it's a fixed size table. It contains only a limited number of branch instructions. By increasing the number of instructions a hundredfold, you also increase the number of branches by that much. This means the number of branches with predictions decreases sharply. In addition, for the branches that are present in the prediction table, less data is available.

Upvotes: 4

Marcelo Cantos
Marcelo Cantos

Reputation: 185852

It will load and run more slowly, and may run out of virtual address space (100 times bigger is pretty dire).

Upvotes: 3

Tony Delroy
Tony Delroy

Reputation: 106096

Less of your program will fit in the CPU caches, disk caches etc. and therefore more time will be wasted as the CPU sits idle waiting for that code to become available. It's as simple as that really.

Ah - I hadn't looked at who'd posted the question - sharptooth hey ? :-) - you obviously won't have learned anything from the answer above. But, that's all there is too it - it's just a statistical balancing act, with defaults doubtless shaped by the compiler writers based on customer pressure to explain both larger executable sizes and slower execution speeds when compared to other compiler vendors.

Interesting if dated lectures notes here: http://www.cs.utexas.edu/users/djimenez/utsa/cs3343/lecture15.html

Upvotes: 2

WuHoUnited
WuHoUnited

Reputation: 8419

Having a bigger executable is its own punishment:

1) It takes more memory to store the program which matters more on some systems than others (cell phones for example can have very limited memory)

2) Having a larger program takes longer to load into memory

3) During execution, you will likely have more cache misses (you try to branch to part of your program which isn't in cache) because your program is spread out over more space. This slows down your program.

Upvotes: 3

chrisaycock
chrisaycock

Reputation: 37930

The main impact will be to the cache. Inlining goes against the principal of locality; the CPU will have to fetch the instructions from the main memory far more often. So what was intended to make the code faster may actually make it slower.

Upvotes: 5

Related Questions