Inline Functions are bad in Large Projects? June 19, 2008Posted by gordonwatts in computers.
This post is rather esoteric C++. Sorry.
I’ve been working on getting some bug fixes in for a new release of the ATLAS code. Actually, it is fairly exciting – if the LHC delivers beam this year (its schedule, though I tend to be a bit of a skeptic) this release of the reconstruction software is what will be used to build that data. How cool is that?
At any rate, the low level rate I/O makes heavy use of templates and inline functions in C++. These exist in the header files (.h, .icc). The other choice, of course, are functions that are not inline, and whose code exist in cxx files. In the former the compiler in general takes care of weaving the functions together with the people that call them. In the latter case it is the linker and the operating system’s loader that takes care of weaving the functions together.
In ATLAS we have patch releases. These are meant to be sent out for small bug fixes for an already produced release. Only a small number of packages of source code can be rebuilt. And there is the rub.
One of the bugs I was fixing was in an inline function, defined in the header. The bug fix was tiny – changed one line of code. Perfect for a patch release. Unfortunately, a number of other packages used this inline function. And so they had to be rebuilt as well. Had that inline function been in the cxx file instead there wouldn’t have been an issue at all.
That caused the issue to be promoted to a full build rather than a small patch release. Just because it was inline. A full rebuild takes overnight for the ATLAS software. The more intertwined our software is, the more of this linkage there is, and the harder it gets to maintain. Inline functions provide you some efficiency gains — you don’t waste CPU cycles creating a new stack frame. But there is a cost most of us don’t think about.