贡献性能优化

SeaTunnel 欢迎针对典型负载的性能优化，以及对已测得性能回退的修复。性能工作应尽早公开讨论， 并提供他人能够复现的证据。Benchmark 可以发现回退，也可以验证对根因的判断，但微基准变快 本身不能证明用户能够获得收益。

发现问题 → 讨论范围 → 受控复现 → 实现优化 → 对比结果 → 评估取舍

形成社区共识

在开始较大的实现之前，请创建或复用 GitHub Issue， 并说明：

• 受影响的负载和 SeaTunnel 执行路径；
• 对吞吐、延迟、资源消耗或作业稳定性的影响；
• 观察问题时使用的环境和证据；
• 预期收益和计划修改的范围。

最初的报告不需要包含完整 Benchmark，但应提供足够证据，供社区讨论问题是否值得解决、计划中的 实验能否代表有意义的 SeaTunnel 负载，以及改动范围是否合适。如果改动涉及多个模块、带来长期 维护责任或需要更广泛的设计决策，请使用 dev 邮件列表 进行讨论。

测得性能提升是社区讨论中的一项证据，不能单独决定结果。社区还会考虑正确性、兼容性、其他 负载、资源取舍、实现复杂度和长期维护成本。

构建可复现的 Benchmark

选择能够代表所报告问题并触达受影响生产路径的负载。明确逻辑操作、输入形态、并发度、预热、 测量时长和计时边界，并说明这些选择与实际 SeaTunnel 负载的关系。方法调用频繁、CPU 占比较高 或出现锁样本，本身都不能证明该路径是瓶颈。

除非 Fixture 构建或结果校验本身就是测试目标，否则应将它们放在计时范围之外。

必须校验输出，避免操作因为少做了工作而显得更快。执行足够多轮，展示正常波动范围，并报告 具有代表性的结果，而不是只挑最好的一次。测试相关的输入规模和并发度，包括可能出现回退的 场景。资源取舍也必须明确，例如通过增加内存获得的吞吐提升并不一定适合所有负载。

本地运行和 Profiling 命令见 Zeta 基准测试。

添加 Benchmark

如果已有 Benchmark 能够代表问题，应优先复用。新增 Benchmark 应满足：

• 负载能够触达受影响的生产路径；
• Fixture 确定，且包含结果校验；
• 运行时间可控，结果足够稳定，可以识别有意义的变化。

当前 Benchmarks Workflow 会在两个版本中分别构建各自的 Benchmark 模块。如果 Benchmark 只存在于优化 PR，Baseline 版本就无法运行它。因此，应先用一个聚焦的 PR 提议新 Benchmark， 让社区可以独立审查负载和测量方法。合入 dev 后，再从包含该 Benchmark 的版本创建优化分支。 合入 Benchmark 是为了建立共同的实验基础，并不预先决定后续提案的结果。

两个版本必须运行相同的实验

Baseline 和 Candidate 必须使用相同的 Benchmark 代码、Fixture、参数、JDK 和测量边界。 其中任何一项不同，结果都无法单独说明生产代码改动带来的影响。

提交并测量性能修复

实现优化时，保持 Benchmark 及其参数不变。运行 Benchmarks Workflow 时：

• seatunnel_ref 填写精确的 Baseline Commit；
• pr_number 填写性能修复 PR 编号；
• 两个版本使用相同的 Benchmark 方法、参数和 JDK。

使用不带 Profiler 的对比量化性能改善或回退。Profiling 可以帮助解释原因，但它引入的额外 开销使其 Score 不适合作为对比结果。

分享证据和取舍

在性能修复 PR 中附上：

• Baseline 和 Candidate Commit SHA；
• 精确的 Benchmark 方法和负载参数；
• JDK、JVM 设置和相关机器信息；
• 对比报告、原始 JMH 结果和多轮运行的波动范围；
• 针对改动路径的正确性和兼容性检查；
• 发现的回退、资源取舍，以及实验未能验证的内容。