如何优化速度#
以下提供了一些实用指南，帮助您为 scikit-learn 项目编写高效代码。
注意
虽然分析您的代码以**检查性能假设**总是很有用，但强烈建议**查阅文献**，以确保所实现的算法是该任务的最新技术，然后再投入到昂贵的实现优化中。
一次又一次地，投入数小时精力优化复杂实现细节的工作，都因后来发现简单的**算法技巧**，或采用了更适合该问题的其他算法而变得无关紧要。
章节 一个简单的算法技巧：热启动 给出了这样一个技巧的例子。
Python、Cython 或 C/C++？#
通常，scikit-learn 项目强调源代码的**可读性**，以便项目用户轻松深入源代码，了解算法在其数据上的行为，也便于维护（由开发人员进行）。
因此，在实现新算法时，建议**开始使用 Numpy 和 Scipy 在 Python 中实现**，注意利用这些库的向量化习语避免循环代码。实际上，这意味着尝试**将任何嵌套的 for 循环替换为等效的 Numpy 数组方法调用**。目标是避免 CPU 将时间浪费在 Python 解释器上，而不是进行数字计算以拟合您的统计模型。通常，考虑 NumPy 和 SciPy 性能提示是一个好主意：https://scipy.github.io/old-wiki/pages/PerformanceTips
然而，有时算法无法用简单的向量化 Numpy 代码高效表达。在这种情况下，推荐的策略如下：
**分析** Python 实现以找到主要瓶颈，并将其隔离在一个**专用的模块级函数**中。此函数将作为编译后的扩展模块重新实现。
如果存在一个维护良好、规模不太大的 BSD 或 MIT **C/C++** 实现的相同算法，您可以为其编写一个 **Cython 包装器**，并将库的源代码副本包含在 scikit-learn 源代码树中：此策略用于类
svm.LinearSVC、svm.SVC和linear_model.LogisticRegression（liblinear 和 libsvm 的包装器）。否则，直接使用 **Cython** 编写您的 Python 函数的优化版本。例如，
linear_model.ElasticNet和linear_model.SGDClassifier类就采用了这种策略。**将函数的 Python 版本移到测试中**，并用它来检查编译扩展的结果是否与黄金标准（易于调试的 Python 版本）一致。
代码优化后（分析无法发现简单的瓶颈），检查是否可以通过使用
joblib.Parallel类实现适用于**多进程**的**粗粒度并行性**。
分析 Python 代码#
为了分析 Python 代码，我们建议编写一个脚本来加载和准备数据，然后使用 IPython 集成分析器交互式地探索代码的相关部分。
假设我们要分析 scikit-learn 的非负矩阵分解模块。让我们设置一个新的 IPython 会话并加载数字数据集，如 识别手写数字 示例所示。
In [1]: from sklearn.decomposition import NMF
In [2]: from sklearn.datasets import load_digits
In [3]: X, _ = load_digits(return_X_y=True)
在开始分析会话并进行初步优化迭代之前，重要的是测量要优化函数的不带任何分析器开销的总执行时间，并将其保存以供以后参考。
In [4]: %timeit NMF(n_components=16, tol=1e-2).fit(X)
1 loops, best of 3: 1.7 s per loop
要使用 %prun 魔术命令查看整体性能概况
In [5]: %prun -l nmf.py NMF(n_components=16, tol=1e-2).fit(X)
14496 function calls in 1.682 CPU seconds
Ordered by: internal time
List reduced from 90 to 9 due to restriction <'nmf.py'>
ncalls tottime percall cumtime percall filename:lineno(function)
36 0.609 0.017 1.499 0.042 nmf.py:151(_nls_subproblem)
1263 0.157 0.000 0.157 0.000 nmf.py:18(_pos)
1 0.053 0.053 1.681 1.681 nmf.py:352(fit_transform)
673 0.008 0.000 0.057 0.000 nmf.py:28(norm)
1 0.006 0.006 0.047 0.047 nmf.py:42(_initialize_nmf)
36 0.001 0.000 0.010 0.000 nmf.py:36(_sparseness)
30 0.001 0.000 0.001 0.000 nmf.py:23(_neg)
1 0.000 0.000 0.000 0.000 nmf.py:337(__init__)
1 0.000 0.000 1.681 1.681 nmf.py:461(fit)
tottime 列是最有趣的：它给出了执行给定函数代码所花费的总时间，忽略了执行子函数所花费的时间。实际的总时间（本地代码 + 子函数调用）由 cumtime 列给出。
注意使用 -l nmf.py，它将输出限制在包含“nmf.py”字符串的行。这对于快速查看 nmf Python 模块本身的热点并忽略其他内容很有用。
以下是相同命令不带 -l nmf.py 过滤器时的输出开头：
In [5] %prun NMF(n_components=16, tol=1e-2).fit(X)
16159 function calls in 1.840 CPU seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
2833 0.653 0.000 0.653 0.000 {numpy.core._dotblas.dot}
46 0.651 0.014 1.636 0.036 nmf.py:151(_nls_subproblem)
1397 0.171 0.000 0.171 0.000 nmf.py:18(_pos)
2780 0.167 0.000 0.167 0.000 {method 'sum' of 'numpy.ndarray' objects}
1 0.064 0.064 1.840 1.840 nmf.py:352(fit_transform)
1542 0.043 0.000 0.043 0.000 {method 'flatten' of 'numpy.ndarray' objects}
337 0.019 0.000 0.019 0.000 {method 'all' of 'numpy.ndarray' objects}
2734 0.011 0.000 0.181 0.000 fromnumeric.py:1185(sum)
2 0.010 0.005 0.010 0.005 {numpy.linalg.lapack_lite.dgesdd}
748 0.009 0.000 0.065 0.000 nmf.py:28(norm)
...
以上结果表明，执行主要由点积操作（委托给 blas）主导。因此，通过用 Cython 或 C/C++ 重写此代码，可能不会获得巨大的收益：在这种情况下，1.7 秒的总执行时间中，近 0.7 秒花费在我们可以认为是最佳的编译代码中。通过重写其余的 Python 代码，并假设我们可以在这部分代码上实现 1000% 的提升（考虑到 Python 循环的浅层性，这极不可能），我们整体上不会获得超过 2.4 倍的加速。
因此，在这个特定示例中，主要的改进只能通过**算法改进**来实现（例如，尝试找到既昂贵又无用的操作，避免计算它们，而不是尝试优化其实现）。
然而，检查 _nls_subproblem 函数内部发生了什么仍然很有趣，如果只考虑 Python 代码，它是热点：它占用了模块累积时间的约 100%。为了更好地理解此特定函数的概况，让我们安装 line_profiler 并将其连接到 IPython
pip install line_profiler
**在 IPython 0.13+ 下**，首先创建一个配置文件
ipython profile create
然后将 line_profiler 扩展注册到 ~/.ipython/profile_default/ipython_config.py 中
c.TerminalIPythonApp.extensions.append('line_profiler')
c.InteractiveShellApp.extensions.append('line_profiler')
这将把 %lprun 魔术命令注册到 IPython 终端应用程序以及其他前端（如 qtconsole 和 notebook）中。
现在重启 IPython，让我们使用这个新工具
In [1]: from sklearn.datasets import load_digits
In [2]: from sklearn.decomposition import NMF
... : from sklearn.decomposition._nmf import _nls_subproblem
In [3]: X, _ = load_digits(return_X_y=True)
In [4]: %lprun -f _nls_subproblem NMF(n_components=16, tol=1e-2).fit(X)
Timer unit: 1e-06 s
File: sklearn/decomposition/nmf.py
Function: _nls_subproblem at line 137
Total time: 1.73153 s
Line # Hits Time Per Hit % Time Line Contents
==============================================================
137 def _nls_subproblem(V, W, H_init, tol, max_iter):
138 """Non-negative least square solver
...
170 """
171 48 5863 122.1 0.3 if (H_init < 0).any():
172 raise ValueError("Negative values in H_init passed to NLS solver.")
173
174 48 139 2.9 0.0 H = H_init
175 48 112141 2336.3 5.8 WtV = np.dot(W.T, V)
176 48 16144 336.3 0.8 WtW = np.dot(W.T, W)
177
178 # values justified in the paper
179 48 144 3.0 0.0 alpha = 1
180 48 113 2.4 0.0 beta = 0.1
181 638 1880 2.9 0.1 for n_iter in range(1, max_iter + 1):
182 638 195133 305.9 10.2 grad = np.dot(WtW, H) - WtV
183 638 495761 777.1 25.9 proj_gradient = norm(grad[np.logical_or(grad < 0, H > 0)])
184 638 2449 3.8 0.1 if proj_gradient < tol:
185 48 130 2.7 0.0 break
186
187 1474 4474 3.0 0.2 for inner_iter in range(1, 20):
188 1474 83833 56.9 4.4 Hn = H - alpha * grad
189 # Hn = np.where(Hn > 0, Hn, 0)
190 1474 194239 131.8 10.1 Hn = _pos(Hn)
191 1474 48858 33.1 2.5 d = Hn - H
192 1474 150407 102.0 7.8 gradd = np.sum(grad * d)
193 1474 515390 349.7 26.9 dQd = np.sum(np.dot(WtW, d) * d)
...
通过查看 % Time 列的顶部值，可以很容易地找出最昂贵的表达式，这些表达式值得额外关注。
内存使用分析#
您可以借助 memory_profiler 详细分析任何 Python 代码的内存使用情况。首先，安装最新版本
pip install -U memory_profiler
然后，以类似于 line_profiler 的方式设置魔术命令。
**在 IPython 0.11+ 下**，首先创建一个配置文件
ipython profile create
然后将扩展与行分析器一起注册到 ~/.ipython/profile_default/ipython_config.py 中
c.TerminalIPythonApp.extensions.append('memory_profiler')
c.InteractiveShellApp.extensions.append('memory_profiler')
这将把 %memit 和 %mprun 魔术命令注册到 IPython 终端应用程序以及其他前端（如 qtconsole 和 notebook）中。
%mprun 有助于逐行检查程序中关键函数的内存使用情况。它与上一节讨论的 %lprun 非常相似。例如，来自 memory_profiler 的 examples 目录
In [1] from example import my_func
In [2] %mprun -f my_func my_func()
Filename: example.py
Line # Mem usage Increment Line Contents
==============================================
3 @profile
4 5.97 MB 0.00 MB def my_func():
5 13.61 MB 7.64 MB a = [1] * (10 ** 6)
6 166.20 MB 152.59 MB b = [2] * (2 * 10 ** 7)
7 13.61 MB -152.59 MB del b
8 13.61 MB 0.00 MB return a
memory_profiler 定义的另一个有用的魔术命令是 %memit，它类似于 %timeit。它可以按如下方式使用
In [1]: import numpy as np
In [2]: %memit np.zeros(1e7)
maximum of 3: 76.402344 MB per loop
有关更多详细信息，请使用 %memit? 和 %mprun? 查看魔术命令的文档字符串。
使用 Cython#
如果 Python 代码分析显示 Python 解释器开销比实际数值计算（例如，向量分量的 for 循环、条件表达式的嵌套求值、标量算术等）的成本大一个数量级或更多，那么将代码的热点部分提取为一个独立的函数，放入 .pyx 文件中，添加静态类型声明，然后使用 Cython 生成适合编译为 Python 扩展模块的 C 程序可能更合适。
Cython 的文档 包含开发此类模块的教程和参考指南。有关 scikit-learn 中 Cython 开发的更多信息，请参阅 Cython 最佳实践、约定和知识。
分析编译后的扩展#
当使用编译后的扩展（用 C/C++ 编写并带有一个包装器，或直接作为 Cython 扩展）时，默认的 Python 分析器是无用的：我们需要一个专用工具来内省编译扩展内部发生的情况。
使用 yep 和 gperftools#
无需特殊编译选项的简单分析使用 yep
使用调试器 gdb#
使用
gdb进行调试很有帮助。为此，必须使用一个具有调试支持（调试符号和适当优化）构建的 Python 解释器。要创建一个新的 conda 环境（构建/安装后可能需要停用并重新激活），其中包含一个源代码构建的 CPython 解释器git clone https://github.com/python/cpython.git conda create -n debug-scikit-dev conda activate debug-scikit-dev cd cpython mkdir debug cd debug ../configure --prefix=$CONDA_PREFIX --with-pydebug make EXTRA_CFLAGS='-DPy_DEBUG' -j<num_cores> make install
使用 gprof#
为了分析编译后的 Python 扩展，可以使用 gprof，前提是用 gcc -pg 重新编译项目，并在 debian / ubuntu 上使用 python-dbg 解释器变体：然而，这种方法还需要将 numpy 和 scipy 用 -pg 重新编译，这相当复杂。
幸运的是，存在两种不需要您重新编译所有内容的替代分析器。
使用 valgrind / callgrind / kcachegrind#
kcachegrind#
yep 可用于创建分析报告。kcachegrind 提供了一个图形环境来可视化此报告
# Run yep to profile some python script
python -m yep -c my_file.py
# open my_file.py.callgrin with kcachegrind
kcachegrind my_file.py.prof
注意
yep 可以使用参数 --lines 或 -l 执行，以“逐行”编译分析报告。
使用 joblib.Parallel 的多核并行#
参见 joblib 文档
一个简单的算法技巧：热启动#
参见术语表条目 warm_start