我如何知道为什么g ++在特定文件上花费很长时间？
我在linux上使用mingw32交叉编译器构建了很多自动生成的代码，包括一个特别大的文件（约15K行）。 大多数文件非常快，但是这个大文件需要很长时间（约15分钟）才能编译。
我尝试过操纵各种优化标志，看看它们是否有任何效果，没有任何运气。 我真正需要的是确定g ++在做什么的一些方法，这需要花费很长时间。 是否有任何（相对简单的）方法让g ++产生关于不同编译阶段的输出，以帮助我缩小可能的挂断？
可悲的是，我没有能力重建这个交叉编译器，因此向编译器添加调试信息并逐步完成它并不是一种可能性。
文件中包含什么内容：
该文件是一个工厂，用于生成某个父类的大量不同的特定子类。 然而，大部分的内容都没有什么特别的花哨。
正如Neil Butterworth所建议的-ftime-report的结果表明，“生命分析”阶段耗时921秒，占据了15分钟的大部分时间。
看起来这发生在数据流分析过程中。 该文件本身就是一堆条件字符串比较，通过以字符串形式提供的类名称构造一个对象。
我们认为改变这一点以指向函数指针的名称映射可能会改进一点，所以我们将尝试一下。
事实上，生成一堆工厂函数（每个对象）并创建一个从对象的字符串名称到一个指向其工厂函数的映射的映射将编译时间从原来的15分钟缩短到大约25秒，这将节省大量的时间在他们的建设。
再次感谢Neil Butterworth提供有关时间报告的提示。
不会提供所有你想要的细节，但试着用-v （详细）和-ftime-report标志运行。 后者产生了编译器所做的一个总结。
它最有可能包括TONNES的包含。 我相信-MD会列出给定CPP文件中的所有包含文件（包括包含内容等等）。
一般来说，g ++的速度减慢是模板。 例如Boost喜欢使用它们。 这意味着很好的代码，很好的性能，但编译速度很差。
另一方面，15分钟看起来非常长。 在Google上快速搜索后，似乎这是明语的常见问题
链接地址: http://www.djcxy.com/p/14979.html上一篇: How do I find out why g++ takes a very long time on a particular file?