Yea, exactly, and as far as I know, the GNU family of compile tools doesn't have these link-time optimizations. I think it's cool that ms has it. And the compiler does have the final say on rather or not it will inline a function. However, if you don't have link-time optimizations (a.k.a., "Whole program optimizations") then small functions in an object file aren't even candidates for inlining outside of that object file.
But as far as inlining vs program size, I agree that it is a good idea to keep small functions that are rarely called in the implementation files because they don't need to be inlined. Inlining does increase the size of your executable. But with the increasing size of processor caches, this impact is reduced, so it becomes a measure of how much speed you gain from not making the function call compared to how much you loose from having to load more code from main memory into the processor cache. Usually, the majority of a program is fairly quickly paged out of the processor cache a few seconds into execution because all of the initialization code is only run once, so the code & data pages that are actually relevant to game play are what tends to reside in the processor cache (and sometimes non-relevant pages even get unloaded from main memory). For Glest, a large part of this occurs when starting the game and it's reading in all of the units & such. After the game starts running, a lot of this code is needed anymore and it's hopefully grouped together and less intermixed with the code you want to keep around. One of the nice features of modern operating systems is that they only load the pages of the executable file that it needs and they let page faults cause whatever it's missing to be loaded from disk, etc. Sorry for the long shpiel.
But as far as which files, it's really a lot of them throughout the project from shared_lib/sources/graphics/particle.cpp to glest_game/type_instances/unit.cpp. The most important ones are the ones that are being called from loops. I can't get the profiling Linux build to actually output a gprof log, but when I do I can find the culprits much better.
Personally, I will sometimes put functions several lines in size in the header file if it seems probably they can be inlined. And just because a function as several lines of text doesn't mean that it has all that many instructions once it's compiled. This is especially true where a function is called using a hard-coded value. If this value causes branching, the compiler will completely remove that code and can inline a function that would otherwise be large, because a portion of it is excluded. I would rather give the compiler a chance than not unless it's a fat ugly function, especially one with a loop that I'm pretty certain would not be a good candidate for inlining. Then again, I do a lot of Java so I'm used to seeing the implementation & definition in the same place.
