deploy

chapter_computational_complexity/summary/index.html

@@ -3685,6 +3685,9 @@
 <p>不是，该图展示的是空间复杂度，其反映的是增长趋势，而不是占用空间的绝对大小。</p>
 <p>假设取 <span class="arithmatex">\(n = 8\)</span> ，你可能会发现每条曲线的值与函数对应不上。这是因为每条曲线都包含一个常数项，用于将取值范围压缩到一个视觉舒适的范围内。</p>
 <p>在实际中，因为我们通常不知道每个方法的“常数项”复杂度是多少，所以一般无法仅凭复杂度来选择 <span class="arithmatex">\(n = 8\)</span> 之下的最优解法。但对于 <span class="arithmatex">\(n = 8^5\)</span> 就很好选了，这时增长趋势已经占主导了。</p>
+<p><strong>Q</strong> 是否存在根据实际使用场景，选择牺牲时间（或空间）来设计算法的情况？</p>
+<p>在实际应用中，大部分情况会选择牺牲空间换时间。例如数据库索引，我们通常选择建立 B+ 树或哈希索引，占用大量内存空间，以换取 <span class="arithmatex">\(O(\log n)\)</span> 甚至 <span class="arithmatex">\(O(1)\)</span> 的高效查询。</p>
+<p>在空间资源宝贵的场景，也会选择牺牲时间换空间。例如在嵌入式开发中，设备内存很宝贵，工程师可能会放弃使用哈希表，选择使用数组顺序查找，以节省内存占用，代价是查找变慢。</p>
 
 <!-- Source file information -->