CodexQA

行业与实践研究与基准测试

40 个场景加权:阿里云用内部基准盯 Qoder 性能回退

CodexQA 团队阅读约 4 分钟

Qoder IDE 合入 39 个性能改动,其中 35 个是少做无用功。40 个场景各按 100 分加权:macOS 综合分从 45.8 到 84.9,Windows 从 41.4 到 74.5。发布前抓住 2 次回退。分数不能当成快了多少。

本文目录

模型天天有榜,IDE 卡不卡却常常靠感觉。阿里云社区在 2026 年 10 月 13 日写的是 Qoder IDE 怎么把性能收成可重复的基准。Qoder IDE 是阿里云的 AI 编程环境。从 1.30 到 1.32,他们持续改性能,合入 39 个相关合并请求,并做了一套覆盖 40 个场景的基准,用来评每一次迭代。硬件变快,软件不一定更顺。文中用 Andy 和 Bill 的说法解释:Intel 的 Andy Grove 和 Microsoft 的 Bill Gates,硬件挤出来的性能,很快被软件越来越大的消耗吃掉。AI 时代代码写得更快,用户还并行跑多个 Agent、让 AI 操作浏览器和电脑、对话也更长。

1. 39 个改动,大多是少做无用功

Agent 有时会引入性能问题,也能把代码、日志和测试放在一起把问题找出来。这 39 个合并请求分四类:去掉不必要的计算 14 个,占 36%;去掉不必要的内存占用 13 个,占 33%;去掉不必要的等待 8 个,占 21%;改进算法时间复杂度 4 个,占 10%。前三类合计 35 个。很多优化只是让软件少做本来可以不做的事。

长对话滚动是一个典型例子。往上翻历史时,界面会把更早的消息插到列表开头。以前,每条消息的 key 用它在「已加载列表」里的位置生成。key 是 React 用来认出单条消息的标识。新消息插到开头后,后面已有消息的位置也变了,同一条消息的 key 跟着变,组件可能被拆掉重装,翻历史就卡。

修法是改用这条消息在当前请求里的固定序号,再拼上会话请求标识,让同一条消息的 key 稳定:

修之前:key = ${requestId}-message-${i},i 是已加载列表里的位置。

修之后:key = ${requestId}-message-${indexInRequest},indexInRequest 是当前请求内的固定序号。

这样再加载更早的消息,React 还能认出并复用已有组件。改动本身只有一行,但只有放在加载历史的上下文里才看得全。让 Agent 对着代码和运行日志查,再验证改完的效果,适合这类问题。

2. 40 个场景,各打 100 分再加权

修完一个问题,下一版会不会又带回来。他们做了内部性能基准:可重复的一套性能测试。从提出到第一版跑出结果,不到一天。把场景补上、加上 macOS 和 Windows、做完初步验证,一共半个月,大约占用一名工程师 15% 的时间。

目前 40 个场景,包括终端命令、工具密集对话里的流式输出、加载长对话、编辑大文件。每个场景按自己的标准打 100 分制,再按使用频率和重要性加权,得到综合分。

从 1.28.0 到 1.32.0,两套系统的内部综合分:macOS 从 45.8 到 84.9,升 39.1 分;Windows 从 41.4 到 74.5,升 33.1 分。1.28.0 和 1.29.0 在这轮优化之前,综合分接近。后面三个版本引入性能优化后,每一版综合分都在涨。

这些数字只跟踪同一套内部基准里版本之间的变化。不能直接说成 Qoder IDE 快了多少,也不能用来给两个操作系统的性能排名。

拆到单个场景更容易看见优化落在哪。macOS 上,从 1.28.0 到 1.32.0:在编辑器里滚动长对话,分数从 9.8 到 77.5;已登录、还带着上次会话标签页的启动,从 23.8 到 81.7;工具密集对话的流式输出,从 14.5 到 63.7。流式输出还在涨,按现在的评分标准仍有余地。全文搜索只从 62.9 到 63.5,几乎没动。综合分上涨不能代替逐个场景看。

权重最高的 13 个场景合计占综合分的 60%,其余 27 个合计占 40%。

3. 发布前抓住两次回退

持续跑这套基准,已经在迭代里抓到两次性能回退,并在发布前修好。性能回退指后面的改动把已经达到的性能做差了。对这个团队,基准的好处是:发布出去之前,能看见哪些变化值得再查。

40 个场景盖不住 Qoder IDE 这么复杂的产品。他们计划扩到 100 个或更多场景,并调整权重,避免单个场景对总分影响过大。重要场景还要单独盯。覆盖更全,更早发现问题的机会更大。新功能、新用法,以及现有基准没覆盖的案例,仍要持续加进去。

如果 Agent 只用来加快做功能,代码会变多,原有的资源浪费也可能继续堆。也可以让它们检查现有代码,找出不必要的计算和内存,再一个个修影响响应的问题。做基准本身也成了 Agent 能帮忙的活:第一版很快跑起来,场景再逐步加,这样每次优化的收益能在后续版本里反复验证。这一次还不能说明 Agent 能打破 Andy 和 Bill 的那个循环。它指出的方向是:做新功能的同时,让 Agent 参与性能排查和持续验证。

阿里云,阿里云社区,How We Made Qoder IDE Smoother with 39 Optimizations,2026-10-13,https://www.alibabacloud.com/blog/how-we-made-qoder-ide-smoother-with-39-optimizations_603632

觉得有用,转给同事

微信扫码

用微信扫一扫,在手机上打开后即可转发。

用 RSS 订阅

提交勘误