4.6 性能优化与大规模数据可视化

4.6 性能优化与大规模数据可视化

本节摘要：当数据点从几百涨到几百万，Matplotlib 的默认画法会越来越吃力——它要把每个点、每条线段都当成独立图元去渲染，点数一多，内存和时间就一起告急。性能优化的核心思路只有一条：减少渲染器实际要画的图元数量，或换一个更快的渲染通道。这一节从"瓶颈在哪"讲起，依次给出降采样、路径简化、选择高效图元、后端选择四条策略，逐条比较它们的收益与代价，让你画出百万级数据也不卡、不死机。

学习目标

阅读完本节，你应当能够：

1. 定位大规模绘图变慢的主要瓶颈（图元数量、渲染后端、内存占用）。
2. 用均匀采样、分箱聚合等降采样手段，在保留趋势的前提下减少点数。
3. 说出 plot 与 scatter 在大量点场景下的性能差异，并选用高效图元。
4. 区分 Agg、SVG、交互式三类后端的适用场景，按需切换。
5. 判断什么时候该把重活交给更专业的库，而不是硬挤 Matplotlib。

一、瓶颈在哪里：渲染器要画多少东西

先建立一个直觉：画 1000 个点和画 1000 万个点，Matplotlib 慢的程度不是线性的"多一万倍数据就多一万倍时间"，但它确实卡在同一个地方——每个点都要作为独立的东西走一遍渲染流水线。就像一条高速路，车少时畅通，车一多，瓶颈不在车有多快，而在收费站要一辆一辆放行。

对散点图来说尤其明显。scatter 会为每一个标记生成一个独立的路径，渲染时逐个处理。点数到了百万级，光是构造这些路径对象就已经把内存和 CPU 都吃紧了，更别说还要一个个画。折线图稍微好一点，因为 plot 把一串点合成一条折线路径，但它内部存的顶点数仍然和你的数据点数一一对应，顶点多了照样慢。

还有一个常被忽略的维度：后端。后端决定"画出来的东西往哪送"。同样一张百万点的图，交给矢量后端去写 SVG，它要把每个图元都翻译成 XML 节点，文件大到打不开；交给位图后端 Agg，它直接把像素写进内存，快得多。所以性能问题从来不是单点问题，是"数据量 × 图元数 × 渲染通道"三者叠出来的结果。

二、降采样与聚合：先给数据减负

最直接、也最有效的策略，是在画之前先把数据"减负"。原则只有一条：在保住趋势和分布的前提下，减少要画的数据点数量。

降采样是减法。均匀采样最省事，用切片步长直接抽点，一百万点每 100 个取一个，剩下一万点，画起来飞快，趋势基本不变。

import numpy as np

x = np.linspace(0, 10, 1_000_000)
y = np.sin(x)

step = 100
plt.plot(x[::step], y[::step])   # 只画一万个点
​

随机采样、首尾采样、按极值采样是它的变体。什么时候用哪种，看你想保什么：均匀采样保整体形状，极值采样保峰值和尖刺，随机采样对分布估计更公平。

聚合是另一种减法，适合散点密度过高的情况。它不"删"点，而是把一片点归并成一个统计值再画。典型做法是按 x 分箱，对每个箱里的 y 取均值，散点图瞬间从百万点变成百来个代表点。

import pandas as pd

df = pd.DataFrame({'x': x, 'y': y})
bins = pd.cut(df['x'], bins=200)
agg = df.groupby(bins, observed=True)['y'].mean().reset_index()
plt.scatter(agg['x'], agg['y'], s=8)
​

如果只是想看二维密度，还有更省事的现成工具：hexbin 和二维直方图 hist2d 直接按格统计，不用你手动分箱。

⚠️ 常见坑：降采样只顾"少"，不顾"代表性"。均匀采样对周期信号是安全的，但如果数据里有稀疏的离群点或突变尖峰，抽点可能恰好把它们跳过去，图看着平滑了，真相也丢了。抽点前先想清楚这张图要传达的是"整体趋势"还是"异常细节"，两者对采样方式的要求是相反的。

三、路径简化与高效图元

减完数据，还能在"图元"这一层继续做文章。

路径简化针对折线。一条折线存的是一个个顶点，但很多顶点其实是近似共线的——它们连起来几乎就是一条直线，却各占一个顶点。Matplotlib 有个开关叫 path.simplify，默认对折线开启，它会自动把这种"可有可无"的中间顶点合并掉，只留拐弯处。顶点少了，渲染就快，而视觉上几乎没有差别。

import matplotlib as mpl

mpl.rcParams['path.simplify'] = True
mpl.rcParams['path.simplify_threshold'] = 0.1   # 简化容差
​

高效图元说的是另一件事：尽量让一次绘制多装一些东西，而不是一个个画。散点图慢，一部分原因是每个标记一个对象；换用 LineCollection 或 PolyCollection 这类集合对象，能把一大批图元打包成一次渲染调用。再退一步，如果你要的是"一条线加几个标记"，别用 scatter，用 plot 配合 markevery，只在线上的部分位置画标记。

plt.plot(x, y, 'o-', markevery=100)   # 线照画，标记每 100 个点才画一个
​

这几招的共同点是：减少的是"渲染器要逐个处理的对象数"，而不是数据本身。数据还在内存里，只是画的时候省了力气。

💡 关键直觉：优化要"从数据到渲染"逐层做。先减数据点数（收益最大），再减图元顶点，再选对后端。顺序反了会事倍功半——你后端再快，百万个散点对象还是要一个个构造。

四、后端选择：换一条更快的路

后端决定图"画到哪、怎么画"。Matplotlib 支持多种后端，性能差异很大，选对能白捡不少速度。

最常用的是 Agg，一个非交互的位图后端。它把图直接渲染成像素，不弹窗口，速度快、内存省，是服务器出图、批量生成图片的首选。要在脚本里固定用它，必须在导入 pyplot 之前设置。

import matplotlib
matplotlib.use('Agg')      # 必须放在 import pyplot 之前
import matplotlib.pyplot as plt
​

SVG 后端走的是矢量路线。它画出来的图能无限放大，但代价是每个图元都要写成 XML，复杂图又慢又大。百万点用 SVG 出图，基本是自讨苦吃。矢量格式适合点数不多、但要进论文排版的场景。

交互式后端（TkAgg、QtAgg 这类）能弹窗口、能缩放平移，但它背着事件循环和重绘的开销。批量出图时不需要交互，就该关掉交互模式或用 Agg，把这块开销省掉。

plt.ioff()   # 关闭交互模式，批量出图时提速
​

还有一个进阶技巧叫"位图化"：在矢量图里，把最密的那些元素标记成栅格。这样最终文件还是矢量格式，但占大头的散点、热力被存成一张位图，文件体积和渲染时间都大幅下降。代价是这部分放大后会有锯齿。

artist.set_rasterized(True)   # 让某个密集图元按位图渲染
​

位图后端还有一个参数值得留意：dpi，它决定每英寸多少像素，也就是图的分辨率。dpi 调高，图更清晰，但像素更多、渲染和文件都更大；dpi 调低，出图快、文件小，但放大就糊。批量预览时用低 dpi 快速看，正式交付再调高，是个省时的常见套路。

图：性能优化四策略对比

⚠️ 常见坑：把 matplotlib.use('Agg') 写在 import matplotlib.pyplot as plt 之后。这时候 pyplot 已经初始化了一个默认后端，再调 use 不会生效，你还会看到一条警告。后端必须在导入 pyplot 之前就定下来，这个顺序错了等于白改。

五、专业库接力：别硬挤 Matplotlib

有些规模，硬优化 Matplotlib 已经不划算了。当数据量到几千万、上亿，每个点都要保留、又要能交互探索，就该考虑专门的库来接力。

Datashader 是这条路的代表。它的思路和 Matplotlib 完全不同：不画"对象"，而是把海量点直接栅格化成一幅图像——先按像素位置统计每个格子落了多少点，再上色。十亿个点也能在秒级出图，因为它的计算量只和"像素数"有关，和"点数"几乎无关。代价是它产出的是一张图，不是可交互的对象模型。

Bokeh、HoloViews 这类库则在交互和流式数据上更强，它们把渲染交给浏览器，能处理动态更新的大数据。这些库不是 Matplotlib 的替代，而是分工：Matplotlib 管"出版级的静态精修图"，它们管"探索级的动态海量图"。

判断什么时候该换，标准很朴素：如果降采样、简化、换后端都做完了还是慢，或者你的需求本质上是"几十亿点的密度图""实时流式刷新的仪表盘"，就别再给 Matplotlib 上强度，直接切到对口的库。工具选对，比代码写快更值钱。

💡 关键直觉：Matplotlib 的性能天花板是"面向对象的渲染"，它总得为每个图元留一个对象。当你需要的不是"一个个对象"，而是"一幅密度图"，就说明该换赛道了——栅格化渲染才是那个量级的正确解法。

六、内存：另一个看不见的瓶颈

性能不只是"慢"，还包括"内存不够"。大规模数据下，内存往往比 CPU 先亮红灯。

第一件事是挑对数据类型。NumPy 默认的 float64 和 int64 各占 8 字节，如果你的数据范围很小——比如像素值 0 到 255、整数计数——用 float32 或 int16 就够，内存直接砍半甚至更多。一亿个 float64 是 800 兆，换成 float32 就 400 兆，这个差距可能就是"能不能跑"的分界线。

arr = np.array(data, dtype='float32')   # 能省一半内存就别用默认 float64
​

第二件事是避免不必要的拷贝。切片返回的往往是"视图"而不是新数组，但有些操作会偷偷触发复制，比如链式索引、类型强转、以及某些 Pandas 的过滤写法。内存吃紧时，多留意哪里在悄悄生成新数组。

第三件事是分块处理。数据大到内存装不下，就用生成器或迭代器一块一块读、一块一块画，每次只让一小块数据进内存。

for chunk in read_in_chunks(source, size=10000):
    ax.plot(chunk[:, 0], chunk[:, 1], alpha=0.3)
​

降采样和分块经常配合使用：先分块读，再在块内降采样，最后把每块的结果叠加到同一张图上。这样既绕开了内存上限，又控制了图元数量。动手优化前先算一笔内存账：点数乘每个点的字节数，再乘一份必要的中间副本，心里有数就不会等到内存报错才回头查。循环出图时还有个小细节：每画完一张就主动关闭它，释放画布占的内存，批量生成几千张图时尤其要记得，否则旧图会在后台越堆越多，内存不知不觉被吃光。

本节速览

• 瓶颈在三个量上：数据量、图元数、渲染通道，三者相乘决定了慢不慢。
• 降采样收益最大：先减点数，均匀、随机、极值、聚合按"保什么"来选。
• 路径简化免费提速：开启 simplify 合并共线顶点，几乎不损视觉。
• 高效图元打包渲染：用 LineCollection、markevery 减少逐个绘制的对象数。
• 后端按场景选：静态批量图用 Agg，矢量排版用 SVG，交互才上图形界面后端。
• 后端设置要趁早：use 必须在导入 pyplot 之前调用，否则不生效。
• 超大规模型换赛道：上亿点、流式仪表盘，交给 Datashader、Bokeh 这类栅格化或浏览器渲染的库。

到这里，第 4 章的六节就走完了。从 Artist 对象模型、坐标变换、Path 和 Patch 这三块"怎么画"的底层，到文本字体、扩展生态、性能优化这三块"怎么画好、怎么画快"的实践，你对 Matplotlib 的掌握已经越过"会用"这条线，摸到了"懂它"的门槛。