关于CPU使用〜优化
我希望程序中的大多数优化问题与高于平常的CPU负载相关联,因为我们说次优程序比理论上需要的更多.但这里的“通常”是一个复杂的词.我不认为您可以选择系统范围的CPU负载百分比的硬值,优化变得有用.
如果我的程序在一个循环中重新分配一个char缓冲区,当它不需要时,我的程序可能运行速度比它需要的慢十倍,并且我的CPU使用率可能比它需要的高十倍,并优化了函数可能会使应用程序性能提高十倍……但CPU使用率仍可能只占整个系统容量的0.5％.
即使我们选择一个CPU负载阈值来开始分析和优化,在通用服务器上我会说30％太高了.但这取决于系统,因为如果你为只运行你的程序的嵌入式设备编程,并且因为它有足够的能力运行你的程序而被选择和购买,那么30％可能相对较低事物的计划.
更进一步,并非所有优化问题都与高于平常的CPU负载有关.也许你只是在睡眠中等待的时间超过实际需要,导致消息延迟增加,但却大大降低了CPU使用率.
tl;博士：你的同事的观点过于简单化,可能与任何有用的方式都不匹配.
关于构建优化级别
但是,关于问题的真正关键在于,在关闭所有编译器优化的情况下部署发布版本是相当不寻常的.编译器设计用于在-O0发出相当简单的代码,并在2016年-O1和-O2进行几乎“标准”的优化.通常期望您将这些用于生产用途,否则您将浪费现代编译器功能的很大一部分.
许多人还倾向于不在发布版本中使用-g,因此部署的二进制文件更小,更易于客户处理.你可以通过这样做将一个45MB的可执行文件丢弃到1MB,这不是口袋改变.
这是否会使调试更加困难？是的,它可以.通常,如果找到了错误,您希望接收再现步骤,然后可以在应用程序的调试友好版本中重复这些步骤并分析由此产生的堆栈跟踪.
但是如果错误无法按需复制,或者只能在发布版本中重现,那么您可能会遇到问题.因此,对(-O1)保持基本优化似乎是合理的,但也要在(-g)中保留调试符号;优化本身不应该大大妨碍您分析客户提供的核心转储的能力,调试符号将允许您将信息与源代码相关联.
话虽这么说,你也可以吃蛋糕并吃掉它：
>使用-O2 -g构建应用程序
>复制生成的二进制文件
>在其中一个副本上执行strip,删除调试符号;否则二进制文件将是相同的
>永远存储它们
>部署剥离版本
>如果要分析核心转储,请根据原始的非剥离版本对其进行调试
您还应该在应用程序中有足够的日志记录,以便能够在不需要任何此类错误的情况下跟踪大多数错误.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
