mirror of
https://github.com/gopl-zh/gopl-zh.github.com.git
synced 2025-12-17 19:24:19 +08:00
fix typo
This commit is contained in:
@@ -1,10 +1,10 @@
|
||||
## 11.5. 剖析
|
||||
|
||||
测量基准对于衡量特定操作的性能是有帮助的,但是当我们视图让程序跑的更快的时候,我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思,但是从原文我们可以看到不同的含义:
|
||||
测量基准(Benchmark)对于衡量特定操作的性能是有帮助的,但是当我们试图让程序跑的更快的时候,我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思,但是从原文我们可以看到不同的含义:
|
||||
|
||||
> 毫无疑问,效率会导致各种滥用。程序员需要浪费大量的时间思考或者担心,被部分程序的速度所干扰,实际上这些尝试提升效率的行为可能产生强烈的负面影响,特别是当调试和维护的时候。我们不应该过度纠结于细节的优化,应该说约97%的场景:过早的优化是万恶之源。
|
||||
>
|
||||
> 我们当然不应该放弃那关键的3%的机会。一个好的程序员不会因为这个理由而满足,他们会明智地观察和识别哪些是关键的代码;但是只有在关键代码已经被确认的前提下才会进行优化。对于判断哪些部分是关键代码是经常容易犯经验性错误的地方,因此程序员普通使用的测量工具,使得他们的直觉很不靠谱。
|
||||
> 我们当然不应该放弃那关键的3%的机会。一个好的程序员不会因为这个理由而满足,他们会明智地观察和识别哪些是关键的代码;但是只有在关键代码已经被确认的前提下才会进行优化。对于很多程序员来说,判断哪部分是关键的性能瓶颈,是很容易犯经验上的错误的,因此这种情况下一般都会借助于工具去实现。
|
||||
|
||||
当我们想仔细观察我们程序的运行速度的时候,最好的技术是如何识别关键代码。自动化的剖析技术是基于程序执行期间一些抽样数据,然后推断后面的执行状态;最终产生一个运行时间的统计数据文件。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user