RoadMap: tick off #5 after the perf series lands

Three perf commits delivered the wins:
- f3f5d27 perf(bench): bench harness for receive/send chains (RoadMap #5 baseline)
- 0b6541c perf(sqlite): swap node:sqlite for better-sqlite3 + cache prepared stmts
- a70f194 perf(msg-push): drop Buffer.from() wrap on pkt.body (free allocation)

Headline numbers (RoadMap #5 baseline → after):

  Bridge — receive pipeline:
    group_member_join (full) 17.5 μs/op →  4.7 μs/op  (~3.7x)
    parseMsgPush text         0.29 μs/op →  0.25 μs/op (~1.2x)

  OneBot — send pipeline:
    storeMeta                17.0 μs/op → 10.9 μs/op  (~1.6x)
    storeEvent               23.2 μs/op → 18.2 μs/op  (~1.3x)
    findMeta hit              5.4 μs/op →  1.3 μs/op  (~4x)
    findMeta miss             3.7 μs/op →  0.7 μs/op  (~5x)
    findEvent hit             3.8 μs/op →  1.7 μs/op  (~2.3x)

  Combined send hot path:    ~40 μs → ~29 μs per message

Stopped here intentionally — the remaining knobs on the list
(elementsToJson sync-fast-path, WAL checkpoint policy, JSON
serialization swap, dedup-on-unchanged identity writes) have
diminishing returns vs the SQLite win we already cashed in.
Bench harness lives on; if real-world throughput pressure shows
up later, the baseline + delta methodology is already wired and
auditable.

All V2.0.0-pre items are now done.
This commit is contained in:
DrSmoothl
2026-05-21 10:37:33 +08:00
parent a70f194218
commit 3f2b474120
+1 -1
View File
@@ -3,7 +3,7 @@
- [x] 优化Debug体验,实现免打包Debug,同时数据目录正确。(Proton兜底思路改成ts+map提取类型,用于tsx和nodejs,vite正常打包的时候剥离)
- [x] 拆分core,架构为Common(公共能力) OneBot(外层封装 协议转换),Core(Api raw能力,基础能力等功能),Bridge(封装和关键解析能力和Event message/sent group/member_add ...)
- [x] 剥离ProtocolBuffer定义到单独package。
- [ ] 整理发送和解析消息链路,提高性能。
- [x] 整理发送和解析消息链路,提高性能。`packages/{bridge,onebot}/bench/*.bench.ts` 拿到了基线数字。最大瓶颈不在 protobuf 解析(已经 sub-μs),而在两处 SQLite 反复 `db.prepare(sql)` 重 parse —— 把 `node:sqlite`(实验性)换成 `better-sqlite3`(稳定)+ 缓存 prepared statements 后:`group_member_join` 全链路 17.5μs → 4.7μs(**3.7x**),`storeMeta` 17μs → 11μs,`storeEvent` 23μs → 18μs,`findMeta` 5.4μs → 1.3μs(**4x**)。送侧组合 hot path(storeMeta + storeEvent)单条消息 40μs → 29μs。另外干掉 `Buffer.from(pkt.body)` 的冗余 alloc(pkt.body 本来就是 Uint8Array)。`elementsToJson` 同步快路径 / WAL checkpoint 调参 / JSON 序列化替换 等次要优化点保留,待真有 throughput 压力再做。
- [x] 对齐NapCat设计采用Api层,挂到ctx,Core与Onebot都这么设计。
- [x] Core 侧:13 个 Api 类(message/contacts/groupAdmin/groupFile/groupAlbum/interaction/friend/profile/forward/misc/extras/web)已挂到 `bridge.apis.<area>.method()`,`BridgeInterface` + `actions/*` 全部删除。
- [x] OneBot 侧:`ApiActionContext` 砍掉 ~40 个纯转发字段(groupAdmin / groupFile / groupAlbum / friend / interaction / message / profile / web 八区),actions 直接 `ctx.bridge.apis.<area>.method(...)` 调用 Core 的 Api 层。保留的 ~30 个字段全是真组合 helper(module-level send/forward、message store reads、meta-lookup composers)。完全 NapCat 化(class-per-action / TypeBox schema / actionName 枚举 / auto-register decorator)暂未做——profile 文档/工具链需求出现后再做。