用OpenCV的HoughLinesP检测直线时，输出的结果里常常混着大量位置相近、角度几乎相同的“重复线”。去重逻辑本身不难写——两两比较距离和角度差，把近似线合并掉。但这个两两比较天然是O(n²)的嵌套循环，当检测出几千条线时，纯Python版本的耗时会让人崩溃。本文记录一次完整的优化过程：把纯Python嵌套循环一步步改写成Numba JIT加速的向量化实现，最终拿到几十倍甚至上百倍的性能提升。
一、原始嵌套循环版本及其性能瓶颈
先看最朴素的写法。假设每条线用端点(x1, y1, x2, y2)表示，去重的思路是：计算每条线的角度和中点，然后两两比较，如果角度差小于阈值且中点距离小于阈值，就认为是同一条线，合并为一组，每组只保留一条代表线。
import numpy as np
def dedup_lines_python(lines, angle_thresh=3.0, dist_thresh=10.0):
# lines: shape (N, 4)，每行是 x1, y1, x2, y2
n = len(lines)
angles = np.zeros(n)
mids = np.zeros((n, 2))
for i in range(n):
x1, y1, x2, y2 = lines[i]
angles[i] = np.degrees(np.arctan2(y2 - y1, x2 - x1))
mids[i] = [(x1 + x2) / 2.0, (y1 + y2) / 2.0]
used = np.zeros(n, dtype=np.bool_)
result = []
for i in range(n):
if used[i]:
continue
used[i] = True
result.append(lines[i])
for j in range(i + 1, n):
if used[j]:
continue
da = abs(angles[i] - angles[j])
da = min(da, 180.0 - da) # 角度差归一化到 0-90
if da < angle_thresh:
dx = mids[i][0] - mids[j][0]
dy = mids[i][1] - mids[j][1]
if dx * dx + dy * dy < dist_thresh * dist_thresh:
used[j] = True
return np.array(result)这段代码逻辑清晰，但问题也很明显。首先是双重循环，n条线要执行n(n-1)/2次比较，n=2000时就是约200万次内层判断。其次，每次迭代里都夹杂着Python层面的属性查找、数组索引和浮点运算，这些操作在解释器里的开销远大于运算本身。
实测下来，n=2000时这个版本在我的机器上要跑大约4秒。对于一帧图像里的直线去重来说，这显然是不可接受的——如果做视频流处理，每帧4秒意味着完全没法用。瓶颈不在算法复杂度本身（O(n²)的成对比较很难避免），而在于“每次比较的常数开销太大”。这正是Numba擅长解决的问题。
二、用Numba JIT改造：从解释执行到机器码
Numba的核心思路是把Python函数即时编译成机器码，编译后的循环性能接近C语言。改造的第一步非常简单：给函数加上@njit装饰器，并把所有数据准备成NumPy数组传入。注意Numba编译后的函数第一次调用会有编译延迟，之后重复调用就是纯机器码速度。
直接加装饰器能提速大约30到50倍，但我们还可以更进一步。真正的优化点是消除Python式的逐元素操作，改成NumPy风格的向量化写法，让Numba生成连续的SIMD指令。关键技巧是用广播机制一次性计算整个成对距离矩阵和角度差矩阵：
from numba import njit, prange
import numpy as np
@njit(cache=True)
def prepare(lines):
n = lines.shape[0]
angles = np.empty(n)
mx = np.empty(n)
my = np.empty(n)
for i in range(n):
x1, y1, x2, y2 = lines[i]
angles[i] = np.degrees(np.arctan2(y2 - y1, x2 - x1))
mx[i] = (x1 + x2) * 0.5
my[i] = (y1 + y2) * 0.5
return angles, mx, my
@njit(cache=True, parallel=True)
def dedup_lines_numba(lines, angle_thresh=3.0, dist_thresh=10.0):
angles, mx, my = prepare(lines)
n = lines.shape[0]
# 广播计算成对角度差矩阵和距离平方矩阵
da = np.abs(angles.reshape(n, 1) - angles.reshape(1, n))
da = np.minimum(da, 180.0 - da)
dx = mx.reshape(n, 1) - mx.reshape(1, n)
dy = my.reshape(n, 1) - my.reshape(1, n)
d2 = dx * dx + dy * dy
used = np.zeros(n, dtype=np.bool_)
result = np.empty((n, 4))
cnt = 0
for i in prange(n):
if used[i]:
continue
# 找出所有与第 i 条线近似的线并标记
for j in range(i + 1, n):
if not used[j] and da[i, j] < angle_thresh and d2[i, j] < dist_thresh ** 2:
used[j] = True
for i in range(n):
if not used[i]:
result[cnt] = lines[i]
cnt += 1
return result[:cnt]这里有几个值得展开的细节。reshape(n, 1)减去reshape(1, n)会触发广播，直接生成n×n的差值矩阵，整个计算在一次底层循环里完成，没有Python对象参与。角度差归一化min(da, 180-da)处理的是类似0度和179度这种“数值差很大但实际几乎平行”的情况，这一步千万别漏，否则去重结果会明显偏差。
prange用于并行化外层循环，Numba会自动把它编译成基于OpenMP的多线程版本。需要注意的是，并行循环里如果多个线程同时读写同一块内存（比如直接在循环内append结果），会引发数据竞争。所以上面的写法把“标记used”和“收集结果”分成两个阶段，前一个阶段里每个线程只负责判断第i条线是否被更早的线覆盖，逻辑上是安全的（严格的并查集写法可以进一步消除竞争，但对去重场景来说这个近似已经足够）。
cache=True也很实用，它会把编译结果缓存到磁盘，程序第二次启动时不用重新编译，对调试和部署体验改善很大。
三、性能对比与进一步调优的坑
实测数据很能说明问题。用随机生成的2000条含重复直线测试：纯Python嵌套循环约4.1秒；仅加@njit不改代码约0.09秒；改成广播向量化加prange并行后约0.011秒。整体提升接近400倍，其中向量化本身的贡献比JIT编译更大——这说明写Numba代码时不能只依赖装饰器，数据布局和运算方式同样重要。
使用过程中有几个常见的坑要提醒。第一，Numba对Python特性支持是子集，列表推导、字典、字符串拼接这些要么不支持要么性能很差，函数内部要全部用NumPy数组思维来写。第二，传入的数组dtype要稳定，float64就是float64，混用float32会触发重新编译。第三，调试阶段可以先用@njit去掉的方式跑纯Python验证逻辑正确性，确认无误后再开JIT，遇到编译报错时Numba的错误信息通常能直接指出不支持的那一行。
还有一个进阶方向：如果线的数量特别大（比如上万条），n×n矩阵的内存开销会达到几百MB，此时可以改用空间划分（按角度分桶，只在相邻桶内做比较）把复杂度降到近似O(n log n)，再配合Numba实现，能同时兼顾内存和速度。另外Hough参数空间本身就带极坐标结构，直接在(θ, ρ)空间做去重往往比在端点空间更稳定，这一点在实现时可以根据实际检测输出的格式灵活选择。
总结一下这次优化的核心经验：先用广播消除Python层循环，再用@njit把代码编译成机器码，最后用prange吃满多核。三层手段叠加起来，嵌套循环类的图像处理代码几乎都能获得两个数量级以上的提速，而且代码结构依然保持简洁可读。