mirror of
https://github.com/krahets/hello-algo.git
synced 2024-12-27 17:16:28 +08:00
49 lines
4 KiB
Markdown
49 lines
4 KiB
Markdown
---
|
|
comments: true
|
|
---
|
|
|
|
# 2.1. 算法效率评估
|
|
|
|
## 2.1.1. 算法评价维度
|
|
|
|
在开始学习算法之前，我们首先要想清楚算法的设计目标是什么，或者说，如何来评判算法的好与坏。整体上看，我们设计算法时追求两个层面的目标。
|
|
|
|
1. **找到问题解法**。算法需要能够在规定的输入范围下，可靠地求得问题的正确解。
|
|
2. **寻求最优解法**。同一个问题可能存在多种解法，而我们希望算法效率尽可能的高。
|
|
|
|
换言之，在可以解决问题的前提下，算法效率则是主要评价维度，包括：
|
|
|
|
- **时间效率**，即算法的运行速度的快慢。
|
|
- **空间效率**，即算法占用的内存空间大小。
|
|
|
|
数据结构与算法追求“运行速度快、占用内存少”，而如何去评价算法效率则是非常重要的问题，因为只有知道如何评价算法，才能去做算法之间的对比分析，以及优化算法设计。
|
|
|
|
## 2.1.2. 效率评估方法
|
|
|
|
### 实际测试
|
|
|
|
假设我们现在有算法 A 和 算法 B ，都能够解决同一问题，现在需要对比两个算法之间的效率。我们能够想到的最直接的方式，就是找一台计算机，把两个算法都完整跑一遍，并监控记录运行时间和内存占用情况。这种评估方式能够反映真实情况，但是也存在很大的硬伤。
|
|
|
|
**难以排除测试环境的干扰因素**。硬件配置会影响到算法的性能表现。例如，在某台计算机中，算法 A 比算法 B 运行时间更短；但换到另一台配置不同的计算机中，可能会得到相反的测试结果。这意味着我们需要在各种机器上展开测试，而这是不现实的。
|
|
|
|
**展开完整测试非常耗费资源**。随着输入数据量的大小变化，算法会呈现出不同的效率表现。比如，有可能输入数据量较小时，算法 A 运行时间短于算法 B ，而在输入数据量较大时，测试结果截然相反。因此，若想要达到具有说服力的对比结果，那么需要输入各种体量数据，这样的测试需要占用大量计算资源。
|
|
|
|
### 理论估算
|
|
|
|
既然实际测试具有很大的局限性，那么我们是否可以仅通过一些计算，就获知算法的效率水平呢？答案是肯定的，我们将此估算方法称为「复杂度分析 Complexity Analysis」或「渐近复杂度分析 Asymptotic Complexity Analysis」。
|
|
|
|
**复杂度分析评估的是算法运行效率随着输入数据量增多时的增长趋势**。这句话有些拗口，我们可以将其分为三个重点来理解：
|
|
|
|
- “算法运行效率”可分为“运行时间”和“占用空间”，进而可将复杂度分为「时间复杂度 Time Complexity」和「空间复杂度 Space Complexity」。
|
|
- “随着输入数据量增多时”代表复杂度与输入数据量有关，反映算法运行效率与输入数据量之间的关系；
|
|
- “增长趋势”表示复杂度分析不关心算法具体使用了多少时间或占用了多少空间，而是给出一种“趋势性分析”；
|
|
|
|
**复杂度分析克服了实际测试方法的弊端**。一是独立于测试环境，分析结果适用于所有运行平台。二是可以体现不同数据量下的算法效率，尤其是可以反映大数据量下的算法性能。
|
|
|
|
如果感觉对复杂度分析的概念一知半解，无需担心，后续章节会展开介绍。
|
|
|
|
## 2.1.3. 复杂度分析重要性
|
|
|
|
复杂度分析给出一把评价算法效率的“标尺”，告诉我们执行某个算法需要多少时间和空间资源，也让我们可以开展不同算法之间的效率对比。
|
|
|
|
计算复杂度是个数学概念，对于初学者可能比较抽象，学习难度相对较高。从这个角度出发，其并不适合作为第一章内容。但是，当我们讨论某个数据结构或者算法的特点时，难以避免需要分析它的运行速度和空间使用情况。**因此，在展开学习数据结构与算法之前，建议读者先对计算复杂度建立起初步的了解，并且能够完成简单案例的复杂度分析**。
|