deploy

chapter_computational_complexity/performance_evaluation/index.html

@@ -3671,14 +3671,14 @@
 </ol>
 <p>也就是说，在能够解决问题的前提下，算法效率已成为衡量算法优劣的主要评价指标，它包括以下两个维度。</p>
 <ul>
-<li><strong>时间效率</strong>：算法运行速度的快慢。</li>
+<li><strong>时间效率</strong>：算法运行时间的长短。</li>
 <li><strong>空间效率</strong>：算法占用内存空间的大小。</li>
 </ul>
 <p>简而言之，<strong>我们的目标是设计“既快又省”的数据结构与算法</strong>。而有效地评估算法效率至关重要，因为只有这样，我们才能将各种算法进行对比，进而指导算法设计与优化过程。</p>
 <p>效率评估方法主要分为两种：实际测试、理论估算。</p>
 <h2 id="211">2.1.1 &nbsp; 实际测试<a class="headerlink" href="#211" title="Permanent link">&para;</a></h2>
 <p>假设我们现在有算法 <code>A</code> 和算法 <code>B</code> ，它们都能解决同一问题，现在需要对比这两个算法的效率。最直接的方法是找一台计算机，运行这两个算法，并监控记录它们的运行时间和内存占用情况。这种评估方式能够反映真实情况，但也存在较大的局限性。</p>
-<p>一方面，<strong>难以排除测试环境的干扰因素</strong>。硬件配置会影响算法的性能。比如在某台计算机中，算法 <code>A</code> 的运行时间比算法 <code>B</code> 短；但在另一台配置不同的计算机中，可能得到相反的测试结果。这意味着我们需要在各种机器上进行测试，统计平均效率，而这是不现实的。</p>
+<p>一方面，<strong>难以排除测试环境的干扰因素</strong>。硬件配置会影响算法的性能表现。比如一个算法的并行度较高，那么它就更适合在多核 CPU 上运行，一个算法的内存操作密集，那么它在高性能内存上的表现就会更好。也就是说，算法在不同的机器上的测试结果可能是不一致的。这意味着我们需要在各种机器上进行测试，统计平均效率，而这是不现实的。</p>
 <p>另一方面，<strong>展开完整测试非常耗费资源</strong>。随着输入数据量的变化，算法会表现出不同的效率。例如，在输入数据量较小时，算法 <code>A</code> 的运行时间比算法 <code>B</code> 短；而在输入数据量较大时，测试结果可能恰恰相反。因此，为了得到有说服力的结论，我们需要测试各种规模的输入数据，而这需要耗费大量的计算资源。</p>
 <h2 id="212">2.1.2 &nbsp; 理论估算<a class="headerlink" href="#212" title="Permanent link">&para;</a></h2>
 <p>由于实际测试具有较大的局限性，因此我们可以考虑仅通过一些计算来评估算法的效率。这种估算方法被称为<u>渐近复杂度分析（asymptotic complexity analysis）</u>，简称<u>复杂度分析</u>。</p>
@@ -3688,8 +3688,9 @@
 <li>“随着输入数据大小的增加”意味着复杂度反映了算法运行效率与输入数据体量之间的关系。</li>
 <li>“时间和空间的增长趋势”表示复杂度分析关注的不是运行时间或占用空间的具体值，而是时间或空间增长的“快慢”。</li>
 </ul>
-<p><strong>复杂度分析克服了实际测试方法的弊端</strong>，体现在以下两个方面。</p>
+<p><strong>复杂度分析克服了实际测试方法的弊端</strong>，体现在以下几个方面。</p>
 <ul>
+<li>它无需实际运行代码，更加绿色节能。</li>
 <li>它独立于测试环境，分析结果适用于所有运行平台。</li>
 <li>它可以体现不同数据量下的算法效率，尤其是在大数据量下的算法性能。</li>
 </ul>