Plotly绘制60万行DataFrame时浏览器响应差异原因排查

安全阿岳

2026-6-17

问题描述

我有一个包含time和data两列、共60万行的DataFrame（df），其中data列仅包含1-4位正负整数；另有单列DataFrame（flags），值为0或三位数，唯一值约4-5个。

使用Plotly绘制交互式散点图时，浏览器（Firefox/Chrome）的响应表现差异极大：

流畅代码：通过lambda直接生成flag_label列，绘图流畅，多次加载也无崩溃：

# Working Algorithm. Plot in browser is fine and browser does not crush no matter how many graphs I load in the same session.
df = pd.concat([df, flags], axis=1)
df['flag_label'] = df[df.columns[2]].apply(lambda x: f'Flag {x}') #works fine
fig = px.scatter(df, x=df.columns[0], y=df.columns[1], color='flag_label',
                        color_discrete_sequence=px.colors.qualitative.Plotly)
fig.update_traces(marker=dict(size=8, opacity=0.7), mode='markers')
fig.update_layout(legend_title_text='Flag #')  
plot(fig) #i have set to

卡顿代码：通过字典映射生成flag_label列，绘制单张图就会导致浏览器卡顿无响应（尝试多种字典映射方法均如此）：

# Sluggish Algorithm. One plot makes browser slow and unresponsive, eg in firefox 
#Note that I tried with several methods found below commented and all provide unresponsive plots
df = pd.concat([df, flags], axis=1)
value_map = {0: "Invalid", 1: "Valid", 2: "Missing"}
converted_dict = {k: value_map[v[0]] for k, v in original_dict.items()}#look below for the original_dict
color_dict={"Valid": 'black','Invalid': 'red','Missing': 'blue'} 


 #df['flag_label'] = df[df.columns[2]].map(converted_dict) #works but it is very sluggish in plotting
 df['flag_label'] = df[df.columns[2]].apply(lambda x: converted_dict.get(x, None)) #works but it is very sluggish in plotting
 #df['flag_label'] = df[df.columns[2]].replace(converted_dict) #works but it is very sluggish in plotting

fig = px.scatter(df, x=df.columns[0], y=df.columns[1], color='flag_label',
                        color_discrete_sequence=px.colors.qualitative.Plotly)
fig.update_traces(marker=dict(size=8, opacity=0.7), mode='markers')
fig.update_layout(legend_title_text='Flag #')  
plot(fig) #undocked in editor

其中original_dict示例如下：

original_dict = {
    999: [2, "Missing measurement, unspecified reason"],
    990: [2, "Missing due to snow-fall"],
    980: [2, "Missing due to calibration or zero/span check"],
    900: [0, "Hidden and invalidated by data originator"],
    899: [2, "Measurement undefined, unspecified reason"],
    890: [2, "Concentration in precipitation undefined, no precipitation"],
    799: [0, "Measurement missing, data element contains estimated string_flag (invalid)"],
    798: [1, "Measurement missing, data element contains estimated string_flag (valid)"],
    000: [1, "Valid measurement"]
    }

两种方式最终可视化结果一致，且绘制的数据量完全相同，请求解析浏览器响应差异的深层原因。

深层原因解析

Plotly分组渲染逻辑差异
第一种方式生成的flag_label是Flag 999、Flag 0这类唯一值数量与原始flag值一致的标签（约4-5个），Plotly会将每个标签对应的数据点拆分为独立的trace（轨迹）渲染；而第二种方式生成的Valid、Invalid、Missing标签，会把大量分散的原始flag数据点合并到同一个trace中。浏览器渲染单个包含几十万数据点的trace时，内存占用和同步计算量远高于多个小trace的总和，直接导致主线程阻塞。
浏览器渲染引擎负载特性
浏览器绘制Canvas/SVG图形时，单个大trace需要一次性处理所有数据点的坐标、颜色、交互绑定，触发密集的同步计算，挤占主线程资源；多个小trace的绘制则可以被引擎拆分到异步任务队列中，分散计算压力，减少卡顿。
DataFrame列类型的隐性影响
第二种方式的字典映射生成的标签重复率极高，Pandas可能自动将其转为category类型以优化内存。但Plotly处理category类型分组时，会生成特殊的内部数据结构，导致渲染时的内存开销和计算复杂度激增。可以通过df['flag_label'].dtype验证，若为category类型，显式转为object类型后再绘图，卡顿情况会明显缓解。
交互事件绑定开销差异
Plotly交互式图表会给每个trace绑定hover、点击等事件监听。单个大trace需要为几十万数据点绑定事件，触发时的计算量远高于多个小trace的总和，这也是浏览器响应迟缓的核心原因之一。

内容的提问来源于stack exchange，提问作者MichaelP