perf: adapt task buffer batch size to backlog

[lcccy5]

你好呀 你看看我的这个优化可以不 谢谢

背景

worker 从溢出任务缓冲区消费任务时，原实现固定每次取 8 个任务。

在低积压场景下，较小批次有利于任务公平性；但在高积压场景下，固定小批次会导致 worker 频繁竞争 taskMu，增加共享缓冲区的锁开销。

改动内容

• 新增基于溢出缓冲区积压深度的自适应批量消费策略：
  • 积压 ≤ 8：每次消费 1 个任务，优先低延迟与公平性；
  • 积压 9–64：每次消费 8 个任务；
  • 积压 65–512：每次消费 32 个任务；
  • 积压 > 512：每次最多消费 64 个任务，降低高负载下的锁竞争。
• 批次大小在持有 taskMu 时计算，避免额外读取队列长度带来的重复加锁。
• worker 复用固定容量的批处理数组，并在任务执行后清空引用，避免空闲 worker 保留已完成任务的数据。

预期收益

• 高积压场景下减少 taskMu 的获取次数，降低溢出队列竞争。
• 低积压场景下维持较小批次，避免单个 worker 长时间占用任务，兼顾任务公平性。
• 不改变任务执行、队列容量和关闭语义。

验证

已执行并通过：

go vet ./...
go test -short ./...
git diff --check

[lcccy5]

你好

[Yiming1997]

@lcccy5 有没有benchmark作为对比？

[Yiming1997]

@lcccy5 项目结构已经更新，你重新拉最新的下来

[lcccy5]

@lcccy5 有没有benchmark作为对比？

batch 1：约 13～14 ns/task
batch 8：约 3.92 ns/task
batch 32：约 2.76 ns/task
batch 64：约 2.4 ns/task
batch128: 约2.38ns/task

[lcccy5]

@lcccy5 项目结构已经更新，你重新拉最新的下来

好的

[Yiming1997]

@lcccy5 补充一下benchmark测试函数

[lcccy5]

现在好了吗 麻烦看看 @Yiming1997

[Yiming1997]

@lcccy5
func BenchmarkAgilePoolSequentialLinkedList(b testing.B) {
for i := 0; i < b.N; i++ {
// 20k worker capacity gives the best performance
pool := agilepool.NewPool(agilepool.NewConfig(
agilepool.WithCleanPeriod(500time.Millisecond),
agilepool.WithTaskQueueSize(100000),
agilepool.WithWorkerNumCapacity(20000),
agilepool.WithIdleContainerType(agilepool.LinkedListType),
))
for j := 0; j < taskCount; j++ {
pool.Submit(agilepool.TaskFunc(func() error {
time.Sleep(10 * time.Millisecond)
return nil
}))
}
pool.Wait()
pool.Close()
}
}
对比原来的实现性能下降了

[Yiming1997]

这是修改后

这是修改前，差异还是比较明显的

[Yiming1997]

这是修改后
这是修改前，差异还是比较明显的

@lcccy5

[Bury-Lee]

PR #92 审核意见：不予通过

感谢提交 PR #92。我已完成对测试结果的审核，并与 main 分支进行了系统性对比。以下为审核结论和具体意见：

---

结论

PR #92 当前不予通过。

使用test工具在 30 个对齐测试场景中，对比了 PR 分支与 main 分支的完成时间。结果显示：

• 22 个场景 PR 更慢；
• 3 个场景基本持平；
• 5 个场景 PR 更快。

具体数据:

差异计算方式：
差异百分比 = (PR耗时 - main耗时) / main耗时 × 100%

#	测试场景	PR #92	main	差异
1	fixed, w20000, t500000, immediate	43.171s	15.150s	+184.9%
2	uniform, w20000, t500000, immediate	45.461s	15.966s	+184.7%
3	normal, w20000, t500000, immediate	44.259s	15.628s	+183.2%
4	fixed, w20000, t20000, linear	142.651s	140.623s	+1.4%
5	fixed, w20000, t10000, poisson	108.441s	107.422s	+0.9%
6	fixed, w20000, t1000000, phased	45.972s	48.802s	-5.8%
7	fixed, w10000, t200000, linkedlist	38.156s	14.129s	+170.0%
8	fixed, w10000, t200000, minheap	38.149s	14.119s	+170.2%
9	fixed, w10000, t200000, slice	38.150s	14.119s	+170.2%
10	fixed, w10000, t200000, ringqueue	38.151s	14.131s	+170.0%
11	fixed, w10000, t200000, block	38.143s	14.122s	+170.1%
12	fixed, w10000, t200000, nonblock	2.001s	2.002s	+0.0%
13	fixed, w100, t20000, immediate	115.229s	103.203s	+11.7%
14	fixed, w500, t50000, immediate	75.166s	51.187s	+46.8%
15	fixed, w2000, t100000, immediate	35.651s	27.637s	+29.0%
16	fixed, w10000, t200000, immediate	38.151s	14.122s	+170.2%
17	fixed, w10000, t200000, task-base=100	8.551s	3.724s	+129.6%
18	fixed, w10000, t200000, task-base=500	38.141s	14.142s	+169.7%
19	fixed, w10000, t50000, task-base=2000	131.144s	19.130s	+585.5%
20	fixed, w20000, t500000, with profile	43.149s	15.168s	+184.5%
21	fixed, w10000, t1000000, phased	45.981s	49.739s	-7.6%
22	fixed, w15000, t1000000, phased	19.251s	19.562s	-1.6%
23	fixed, w10000, t1000000, nonblock, phased	31.340s	32.441s	-3.4%
24	normal, w20000, t15000, poisson	126.990s	128.582s	-1.2%
25	uniform, w10000, t10000, nonblock, linear	130.945s	130.932s	+0.0%
26	fixed, w20000, t15000, constant	127.801s	127.411s	+0.3%
27	fixed, w5000, t1000000, task-base=1	1.509s	1.425s	+5.9%
28	fixed, w500, t5000, task-base=3000	31.106s	31.107s	+0.0%
29	fixed, w10000, t200000, -e 3	41.143s	17.130s	+140.2%
30	uniform, w10000, t8000, minheap, nonblock, -e 5	151.111s	149.923s	+0.8%

PR 分支总耗时为 1815.065s，main 分支为 1352.779s，总耗时增加约 34.2%。
更严重的是，PR 重点关注的高并发、immediate、溢出缓冲区等场景出现明显性能回归，部分场景慢达 170%–185%，最严重场景慢约 585.5%。

---

主要问题

1. 性能回归显著，未达预期收益

   • 高并发 immediate 场景（如 w20000, t500000）PR 慢约 184%；
   • task-base=2000 场景 PR 耗时 131.144s，main 仅 19.130s，慢约 585.5%；
   • 虽有个别 phased 场景略快，但收益不稳定，无法抵消整体回归。

2. 新增逻辑缺少单元测试覆盖

   • adaptiveTaskBatchSize 无边界测试；
   • PopAdaptiveBatch 缺少批量行为、FIFO、chunk 边界、任务守恒等验证；
   • 无阈值（如 8/9、64/65、512/513）和截断行为的专项测试。

3. 缺少可复现的性能对比数据

   • PR 自带 benchmark 仅运行当前版本，未提供与 main 的对比；
   • 资源占用（内存、GC、CPU）数据口径不一致，无法得出有效结论。

4. 关键阈值缺乏实验依据

   • 批量大小选择（如 8、64、512）未提供适配不同负载的数据支撑。

---

最终意见

PR #92 我们无法批准合并。如果要重新提交,建议使用test工具完成测试,确认新版本性能更优后提交

---

如有疑问，可随时在此 PR 下讨论或联系审核人。感谢你的贡献与理解。