Inline Functions are bad in Large Projects? June 19, 2008
Posted by gordonwatts in computers.trackback
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.
Life as a Physicist 
How about a rule like “Don’t inline functions that are sufficiently complex to have a potential for bugs”?
Ha! I don’t think I’ve ever met a function that didn’t have that property.
I guess getters and setters would probably satisfy this requirement.
But then when you go to template functions you effecively inline every single function, unfortunately. This particular problem had exactly to do with a template method – so no matter how complex it was always going to be inlined. 😦
The problem is much deeper. There is not really any separation between interface and implementation in C++. You are obliged to expose parts of your implementation (things which should be hidden) in header files, which are seen by everyone else. One consequence is that you should recompile everything even when interface doesn’t change (as in your case). Another consequence is very long compilation time; compiler compiles in fact much bigger files than you implementation – it includes headers from many other classes.
This is exactly correct, hrivnac.
Ironically, however, at least in ATLAS, the compile step is fast — everything that has to be done to get to the compile step, however, is very slow (the build system).
The compile step is fast in comparison with other steps. However, the compile step in Atlas/C++ is incredibly slow if you compare it with some other languages. I have Java projects, where I compile several hundred classes in several seconds.
In fact, slowness of other steps comes probably mostly from the same source. Your end-user class may be very simple, but it depends on just everything else via repetitive include files. So the system has too get them first even before it starts doing anything serious. And when you are on AFS, it is already the amount of data you have to read (i.e. to move to your machine) which kills you. The same when you try to create libraries, build dictionaries,…
Even when your project may look very modular, it is not modular at the system level.
But it can be — there are books on this sort of linkage – which instruct you how to avoid it. Sadly, few of particle physists have read them!
[…] (from the dicsussion on the blog of Gordon Watts) […]
The compile step is fast in comparison with other steps.