Makie.jl 中 `density` 和 `xticks` 导致的性能问题分析

在数据可视化库 Makie.jl 中，用户可能会遇到一个意外的性能问题：当同时使用 density 绘图函数和手动设置 xticks 时，会导致严重的性能下降和内存分配激增。本文将深入分析这一问题的成因，并提供几种解决方案。

问题现象

当用户创建一个包含 density 绘图和自定义 xticks 的图表时，会出现以下情况：

1. 执行时间显著增加：从正常的 0.1 秒激增至 5.6 秒
2. 内存分配暴涨：从 15MB 增加到惊人的 11.6GB
3. GC 时间占比高：垃圾回收时间占总执行时间的 12.5%

根本原因

这一问题源于 Makie 的自动刻度生成机制，特别是次要刻度(minorticks)的计算方式：

1. 刻度步长计算：当用户设置 xticks=0:50:500 时，系统检测到主要刻度步长为 50
2. 坐标轴范围异常：density 绘图默认会设置一个非常大的 x 轴范围(-1e9 到数据最大值)
3. 次要刻度爆炸：系统尝试在 -1e9 到 220 的范围内，以步长 50 生成主要刻度，并在每对主要刻度之间生成 2 个次要刻度
4. 数量级问题：这导致生成了约 2000 万个刻度值，造成严重的性能问题

解决方案

1. 显式设置坐标轴范围

在显示图表前，使用 xlims!() 函数明确设置合理的 x 轴范围：

xlims!(ax, 0, 250)  # 设置合理的范围

2. 关闭自动范围调整

对于 density 绘图，可以禁用自动范围调整：

density!(ax, [-1e9]; xautolimits=false, ...)

3. 后设置刻度

先创建图表并设置数据，最后再调整刻度：

ax = Axis(fig[1,1]; yscale=log10)  # 初始不设置xticks
# ... 添加绘图 ...
ax.xticks = 0:50:500  # 最后设置刻度

最佳实践建议

1. 始终考虑坐标轴范围：当使用可能产生极大范围的数据时，应主动控制坐标轴范围
2. 分步调试：先创建基本图表，再逐步添加复杂元素，观察性能变化
3. 替代方案：对于仅需要图例项的情况，考虑使用 PolyElement 等更轻量级的方式

总结

这一性能问题揭示了数据可视化中一个常见陷阱：自动范围调整与自定义刻度的交互可能产生意外的数量级问题。通过理解 Makie 的内部机制，用户可以更有效地控制图表行为，避免类似的性能瓶颈。记住，在数据可视化中，显式控制往往比依赖自动调整更加可靠。