Mik*_*ike 6 compiler-construction gcc gnu inlining icc
考虑到你只是在尝试优化速度,在决定是否内联函数时,有什么好的启发式方法？显然代码大小应该很重要,但是当(例如)gcc或icc确定是否内联函数调用时,是否还有其他因素？该地区是否有重要的学术工作？
JIT编译器和运行时类加载的语言有其他权衡,因为虚拟方法不是静态知道的,但JIT可以收集运行时分析信息,例如方法调用频率:
即时编译器 (for Java)中的优化设计,实现和评估讨论了静态方法和动态加载类的方法内联及其对性能的改进.
练习JUDO:Java动态优化声称他们的"内联策略基于代码大小和分析信息.如果方法条目的执行频率低于某个阈值,则该方法不会内联,因为它被视为冷为了避免代码爆炸,我们没有内联一个字节码大小超过25个字节的方法......为了避免沿着深度调用链内联,当沿着调用链累积的内联字节码大小超过40个字节时内联停止".虽然它们具有运行时分析信息(方法调用频率),但它们仍然小心避免内联大型函数或函数链以防止膨胀.
对Google学术搜索的搜索显示了许多论文,例如
对Google图书的搜索显示了大量有关各种情境中的函数内联的论文或章节的书籍.
编译器设计手册:优化和机器代码生成有一章关于编译器设计中的统计和机器学习技术,启发式设置各种参数,分析结果.本章参考了Vaswani等人的论文" 针对编译器优化的微架构敏感经验模型 ",他们提出了"使用经验建模技术构建用于编译器优化的微体系结构敏感模型".
(其他一些书谈论程序员的观点,例如游戏程序员的C++,它讨论了过于频繁地内联函数的危险以及内联和宏之间的差异.编译器经常忽略程序员的内联请求,如果他们能够确定的话他们会弊大于利;作为最后的手段,这可以用宏来覆盖.)