Hi Rohit Garg, > I have a small app. In it in a a particular place, I had a 2-3 > functions being called from one main function. They were small > functions (5-6 lines) and inline keyword was used. The performance was > ......... HORRIBLE. > > -Winline didn't report any case of a function not being inlined. > > I didn't know where to start. So I manually inlined these functions. > They are very small and quite trivial. The program now shows ~60x > speed-up in that part of the code. I have no idea what's the cause of > this dramatic speed up. But I suspect it is because I am using g++ to > make a shared library. All the functions referred to here are in one > file. It is complied by using a -c -fPIC option to make a .o file. > Several .o files are later packed together into a .so file using a > -shared option. > > Is my guess correct? I'd have to see your code and how you are compiling it to understand why your code's performance was horrible. As one possibility, I'm guessing that you were expecting routines in the shared object (.so) to be (somehow) inlined into your main executable. If this is the case, I understand that some GCC internals folks are trying techniques that would do holistic analysis and optimization... but I doubt that such techniques would ever (or should ever) pull inlines from across the .so boundary at link time. Only if those techniques could be done at runtime (ala Java and the JVM) or load time, but not at compile time or link time.* Sincerely, --Eljay * I don't pretend to understand how this black magic can be accomplished. But if it is possible, and there is a good performance win, I expect that GCC will be near the forefront to incorporate that technique / technology. Also, GCC would be but one piece of the puzzle. The black magic inlining ABI would have to be honored by several different parts of your OS: the compiler, the assembler, the linker, the loader, perhaps even the runtime.
