开发工具版本控制【免费下载链接】vscode-gitlensSupercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more项目地址https://gitcode.com/gh_mirrors/vs/vscode-gitlens点击查看免费下载本文深入解读 GitLens 仓库中/live-perf技能.claude/skills/live-perf/SKILL.md的完整方法论如何在正在运行的扩展里对某个功能做性能测量、建立基线、按Measured / Conventions / Speculation三层纪律派发修复 Agent并循环重测直至无回归。读完本文你将掌握一套可直接复用的测量优先、规范优先、杜绝臆测的性能改进工作流并了解其与仓库内 MCP 工具链、RPC 日志层、memoize装饰器及 git 调用测试的对应关系。一、/live-perf 是什么一次测量驱动的性能闭环/live-perf是 GitLens 为 Agent 定义的一等技能其核心信条只有一句话Measure-first or dont touch. Speculation goes to open-questions, never to agents.先测量否则不要动代码臆测一律进 open-questions绝不派发给 Agent。该技能用于三种典型场景独立使用Standalone对既有功能做性能调优而无需走完整的/live-exercise功能审计。典型目标包括渲染回归、RPC 消息频繁程度chattiness、git 调用风暴git-call storms、热路径上缺失的缓存。被/live-exercisePhase 7 委托作为发布前ship-gate收敛循环的一部分被调用属于先修功能、再调性能流水线的最后一环。/live-perf明确声明不适用的场景同样重要对没有被测量出慢的代码做投机性优化当功能性与意图本身存疑时替代/live-exercise应先修功能再对可工作的部分做性能调优完全没有实时测量支撑的静态代码审查。与其他技能的分工Skill用途模式/live-inspect底层 MCP 工具参考原始Primitive/live-exercise审计与修复循环功能、意图、打磨、改进实时 迭代/live-perf性能测量 改进循环实时 测量/review规范与完整性检查清单静态/deep-review代码路径正确性追踪静态可以看出/live-perf是五个技能中唯一同时要求实时与测量的——它不信任静态推理一切结论必须以数字或既定规范为依据。二、前置条件MCP 工具链与构建验证技能执行前需要满足三个前置条件这些条件在仓库中都有实际落点vscode-inspectorMCP 已连接。仓库根目录的 .mcp.json 已经声明了该服务器{ mcpServers: { vscode-inspector: { command: node, args: [scripts/mcp-vscode-server.mjs] } } }对应的服务端实现位于 scripts/mcp-vscode-server.mjs它暴露了/live-perf全流程依赖的原始工具launch启动 VS Code、evaluate_in_webview在 webview 内执行 JS 并取回数值、evaluate在扩展宿主侧执行、read_logs读取日志、read_console、list_webviews等。构建通过pnpm run build:quick。该脚本定义在仓库 package.json 中build:quick: node ./scripts/build.mjs --quick是每次派发修复 Agent 之后必须运行的验证命令。能识别 Scope范围特性、生命周期阶段、用户流程、diff、后台操作或临时代码路径——对一切做性能优化的模糊调用不属于本技能范畴。三、三维轴Scope / Exercise / Baseline每次/live-perf调用都沿着三个轴展开轴值从用户请求中推导框架本身三层纪律、收敛循环、退出条件不变只有轴值变化。轴值需要记录在baseline.md顶部以保证意图可审计。轴 1 —— Scope测量什么Scope 类型示例FeatureCommit Graph 滚动、Home 水合hydration、Timeline 过滤器Lifecycle stage扩展激活、首次打开仓库、认证之后User flow冷启动 → 打开仓库 → 图表 → 点击提交 → 检视Diff-derived本分支的改动git diff base...HEAD、特定提交Background op自动 fetch、后台索引器、状态栏刷新、watcherAd-hoc code path用户指定的某个方法或入口点轴 2 —— Exercise如何驱动策略选择时机用户式交互User-like interactionScope 有可见 UI 入口Feature / 流程的默认选项程序化触发Programmatic trigger没有 UI 入口或需要精确计时execute_command、事件派发、evaluate环境观察Ambient observation后台/定时类操作——让其自然发生观察一段时间窗口冷启动Cold launch生命周期/激活类 Scope——拆除 重启以强制冷态压力变体Stress variant规模/竞争关注——快速重复、并发动作、大数据输入轴 3 —— Baseline拿什么对比策略选择时机绝对阈值Absolute threshold有已知预算如水合 ≤150ms、每个动作 ≤3 次 git 调用。有预算时是默认项既有基线Prior baseline回归排查——与上次捕获的baseline.md或main分支对比分支对比Comparative branchDiff 类 Scope——同一驱动方式下本分支 vs 基分支多次平均Averaged runs 3–5随机性指标墙钟时间、渲染时序。计时类默认项配对测量Paired measurements规模问题——冷/热、小数据/大数据、压测前后默认组合表如果用户说…ScopeExerciseBaselinestartup time激活生命周期冷启动绝对 多次平均feature X特性用户式绝对 多次平均this branchdiff 派生特性逐特性用户式与基分支对比background fetch后台操作环境观察绝对CPU/IO 预算large repo / N commits特性 数据形态大仓库上用户式小-大配对why is X slow用户指定流程程序化或用户式绝对 分阶段分解如果任一轴无法确定技能要求只问用户一个问题Whats the scope — a specific feature, a lifecycle stage (activation/startup), a cross-feature user flow, the diff on this branch, or a background operation?然后按默认组合表推断其余两轴。四、测量四类别渲染、RPC、热路径、Git 调用无论 Scope 是什么每一轮测量都必须覆盖四个类别确实不适用时才跳过且需记录跳过原因。原技能特别指出在 Opus 上运行时原始测量采集默认委托给inspector-driver子 AgentSonnet 5——通过Agent({ subagent_type: inspector-driver, model: sonnet, prompt: 精确探针 })传入确切的探针performance.now()差值、updateComplete时序、通知计数、采样数 N。子 Agent 只负责返回数字三层分类Measured/Convention/Speculation与所有修复决策始终由主 Agent 保留。冷启动指标与基线↔修复后对比需按重置规则复用已启动实例或自行采样。1. 渲染 / Webview 性能测量内容每个 webview 的首次渲染 水合时间从launch/刷新到 Lit 的updateComplete状态切换期间的重复渲染频率Lit 组件updated()计数布局抖动 / 强制回流Performance API 的layout-shift、长任务动画/过渡流畅度合成 vs 主线程、掉帧。工具evaluate_in_webview配合performance.now()、PerformanceObserver、performance.getEntriesByType(measure)以及针对 Lit 的document.querySelector(...).updateComplete。关于多 webview 性能技能给出一个关键提醒当同时打开 2 个以上 webview 时未指定目标的evaluate_in_webview会静默运行在第一个通常不是你想要的那个里。必须先执行list_webviews再用webview_url/webview_index限定每次测量。2. RPC / 数据传输测量内容每个用户动作触发的通知数按类型计数每条通知的负载大小大数组会被标记N1 模式请求循环而非批量拉取每个流程的往返次数。工具与仓库落点通过evaluate_in_webview对 RPC 层插桩包裹 src/webviews/apps/shared/rpc/rpcController.ts 下的RpcController/RpcClient。该文件是 webview 侧的 RPC 控制器实现RpcControllerTServices implements ReactiveController, WebviewRpc其hostConnected/hostDisconnected生命周期里管理长连接与按会话挂载的服务代理。日志侧使用read_logs检索RpcHost/RpcLogger流量——src/system/rpc/logger.ts 提供了createSupertalkLogger(prefix)与formatWebviewLogTag(webviewId, webviewInstanceId)日志行会形如[RPC:host(gitlens.views.commitDetails|5cf1bc7c)]或[RPC:client(gitlens.views.timeline|4103a120)]每个通道都能在日志中被精确识别。该文件的注释还说明它会把 Error-like 参数归一化为name: message形式避免 JSON 序列化时把异常打成{}这保证了日志中通知负载与错误的可读性。扩展宿主侧则用read_logs按通知名做模式匹配。3. 热路径代码审计纯代码级不测量审计内容未缓存的重读操作多次 await 同一个 getter / provider 方法纯函数且高频调用的 getter 上缺少memoizegit 派生数据未用GitCache/PromiseCache本可Promise.all却串行await的代码高频事件scroll、resize、input、mousemove缺少 debounce / throttle。审计对象是 Scope 覆盖的代码——某个特性的源码、某个分支的 diff、激活路径等用 Read 与 Grep 完成。仓库中memoize的行为有完整测试佐证src/system/decorators/tests/decorators.test.ts 的memoize套件覆盖了默认用法、自定义resolver、以及memoize({ version: providers })的版本化失效——这正对应每次memoize都是关于身份与失效的一次决策这一技能断言。4. Git 调用关键认知git 调用的成本在 spawn进程创建而非执行本身。测量/审计内容跨组件的冗余 git 命令一次用户动作触发了多次相同的git log/git status未批处理解析每条命令只取一条信息而不是从单次输出解析多条重复调用方缺少缓存相同 git 结果被重复拉取git 触发的刷新风暴一次外部变更引发 N 次刷新。工具与仓库落点read_logs配合 git 命令日志模式匹配GitLens 开启 debug 日志后会记录 git 调用代码审计模式参考 packages/git-cli/src/providers扩展宿主侧用evaluate在一个用户动作窗口内统计命令调用次数。仓库的集成测试直接印证了这些关注点packages/git-cli/src/providers/tests/integration/branches.test.ts 中 a local miss is cached, so repeated lookups spawn once 断言缓存未命中后重复查询只 spawn 一次symbolic-refpackages/git-cli/src/providers/tests/integration/config.measure.test.ts 用spawn-counter通道精确计数一次分支总览渲染原先对每个命名空间各 spawn 一次--get-regex4 次现在改为一次批量读取1 次packages/git-cli/src/providers/tests/integration/commits.test.ts 验证被取消的调用方不能误杀共享同一次 in-flight spawn 的并发调用方。这些测试正是一个用户动作 3 次 git 调用即可疑这条阈值的实现基础。五、三层纪律Measured / Conventions / Speculation每个发现都必须归入三层之一层决定是否派发 Agent 以及按什么规则派发| 层 | 规则 | 动作 | ID 前缀 | | -- | ---- | ---- | ------- | |Measured| 相对基线有量化回归或可测量的热路径超过阈值 |派发修复 Agent修复后必须重新测量确认改进 |PR| |Conventions| 违反 GitLens 规范热 getter 漏缓存/漏 memoize、串行 await、缺 debounce |派发自由修复 Agent在decisions.md记录条目。无需基线——规范本身就是 bug |PC| |Speculation| 这个也许能更快——无测量、无既定规范 |记入open-questions.md不碰代码|PS|三条铁律Measured 层必须先测量动手前捕获基线修复后捕获新测量。如果修复后相比基线没有改进就回滚并重新调查——不发布没效果的修复。Convention 层可仅凭审计派发重复的纯 getter 上缺memoize本身就是 bug不需要先量化收益再修。Speculation 永不派发测不出来、又不是规范违反那就是给用户的开放问题。六、工作循环七步收敛步骤 1 —— 推导 Scope / Exercise / Baseline从用户调用、/live-exercise交接或默认组合表为三轴各取一个值任何轴不明确就问那一个问题。从/live-exercisePhase 7 进入时Scope 是 live-exercise 正在跑的对象Exercise 默认用户式Baseline 默认绝对 多次平均。独立调用时按默认组合表映射。若存在goals.md读取其中声明的性能要求阈值、预算它们会成为轴 3 的目标。把选定的轴记录在baseline.md顶部。步骤 2 —— 基线采集不改代码若 VS Code 未运行则launch。按轴 2 的 Exercise 策略驱动开启相关日志/插桩git debug 日志、RPC logger、PerformanceObserver按策略驱动用户式点击/滚动/输入走完整流程按基线策略重复程序化execute_command、事件派发或evaluate按基线策略重复环境观察保持 VS Code 运行观察 2–5 分钟不去驱动冷启动每次运行都拆除 重启启动类必须每次冷态压力按配对测量需要做快速重复、并发或大数据变体对适用类别采集测量渲染用evaluate_in_webviewperformance.measure/updateCompleteRPC 用日志解析通知计数与负载Git 用read_logs计数热路径仅审计不测量把基线数字写入.work/live/feature-perf/baseline.md# Feature — Perf Baseline Recorded: ISO date ## Render - Home webview hydration: 220ms (avg 5 runs) - Repeat render on branch switch: 85ms ## RPC - Notifications per branch switch: 12 - DidChangeRepositoriesNotification payload: 48KB ## Git - Commands per branch switch: 7 (3x git log, 2x git status, 2x git rev-parse)步骤 3 —— 评估测量 规范审计把测量结果与以下内容对比阈值通用指引webview 水合 150mswebview 刷新 100ms单个用户动作 3 次 git 调用可疑单个动作 5 条通知可疑既有基线上一轮.work/live/feature-perf/baseline.md或 git 历史goals.md中的声明要求。同时用 Read Grep 对 Scope 代码做规范违规审计。技能提醒阈值是启发式而非教条——超过阈值且用户可感知的才是真问题。步骤 4 —— 汇总发现写入.work/live/feature-perf/findings.md# Feature — Perf Findings ## Status | ID | Tier | Category | Title | Status | Baseline → Target | | ------ | ----------- | -------- | ----------------------------------------- | ------ | ----------------- | | I1-PR1 | Measured | Render | Home hydration 220ms (threshold 150ms) | open | 220 → 150 | | I1-PC1 | Convention | Hot-path | Missing memoize on GitProvider.getBranch | open | — | | I1-PS1 | Speculation | Git | Could batch logstatus into one spawn | see Q1 | — | ## Measured (PR) ### I1-PR1 — Home hydration exceeds threshold - **Baseline**: 220ms avg over 5 runs (fresh launch → gl-home-app.updateComplete) - **Target**: 150ms - **Hypothesis**: RPC warmup serialized; Lit templates heavy - **Fix direction**: check if Home state can be prefetched / cached; audit Lit template for unused imports ## Convention (PC) ### I1-PC1 — Missing memoize on getBranch - **File**: packages/git-cli/src/providers/branches.ts:L88 - **Convention**: pure getter called in render paths → must be memoized - **Evidence**: grep shows 7 call sites, 3 in render paths - **Fix**: add memoize() decorator ## Speculation (PS) ### I1-PS1 — Could batch logstatus into one spawn - Moved to open-questions.md Q1投机性条目写入.work/live/feature-perf/open-questions.md## Q1. Batch log status for branch switch? Currently 2 git spawns per branch switch. Could batch via combined git log --name-status parsing. **Pros**: saves ~30ms/switch (~estimated, not measured) **Cons**: touches parser layer, risk of parser bugs, speculative savings **Recommendation**: file for later unless branch-switch latency is user-visible bad步骤 5 —— 派发修复 Agent仅 Measured Conventions对每条 Measured 和每条 Convention 发现归组相关修复如同一文件内的所有memoize补充 → 一个 Agent并发上限 5–6 个每个 Agent 的 prompt 必须包含精确文件路径 行号层级Measured 或 ConventionMeasured 层基线数字 目标。Agent 必须通过实时重测验证改进而非假设Convention 层被违反的规范 应套用的规范模式验证命令pnpm run build:quick项目规范.js导入扩展名、无 barrel 文件、无顺手重构drive-by refactors、不用--no-verify明确的 out-of-scope。Speculation 永不派发那是用户通过 open-questions.md 决定的事。子 Agent 必须重测不能假设派发 Measured 层修复时prompt 必须要求子 Agent 在修复后重新驱动功能并重新采集测量。示例 promptFix the Home hydration baseline of 220ms by [approach]. After the fix, rebuild withpnpm run build:quick, relaunch VS Code via the vscode-inspector MCP, re-exercise fresh-launch → Home →updateComplete5 times, capture the new average. Report the baseline → post-fix numbers. If post-fix baseline, revert and report.步骤 6 —— 验证与循环Agent 完成后pnpm run build:quick修复一切破坏每个 Agent 之后都要git diff——不要盲信任何东西为重新测量做重置冷启动/启动类指标与每次基线↔修复后对比都需要完整拆除 重启——缓存状态会毁掉基线。同一构建内的热操作样本渲染/RPC/git可以复用运行中的实例并重新触发但代码变更后必须先全新构建 重启修复后的数字才算数重新驱动功能对 Agent 触碰过的所有指标重新采集更新findings.md修复后超过目标 → 标记完成未改进 → 保持 open 并重新调查不发布不是修复的修复修复导致其他指标回退 → 进入下一轮新发现Convention 修复落地后重新审计确认模式已一致回到步骤 2 循环直到无遗留发现、也无新发现浮现。步骤 7 —— 退出满足以下全部条件才退出所有 Measured 发现都有已验证的改进或被重新分类连同理由移入 open-questions所有 Convention 发现已修复Speculation 条目已归档到 open-questions 供用户审阅重新采集的基线没有新回归。从/live-exercisePhase 7 进入时退出即把控制权交还 live-exercise若本轮产生变更live-exercise 回到其 Phase 5 循环Speculation 条目随 live-exercise 的open-questions.md一起呈现给用户。七、陷阱清单与循环红线常见陷阱陷阱后果缓解投机性优化Agent优化了从未变慢的东西可能引入 bug、零收益Speculation 层永不派发归档到 open-questions只测一次噪声驱动的结论改进只是方差每个测量 3–5 次报告均值与散布修复前无基线无法确认修复是否真的有用派发任何东西前先采基线Measured 层强制信任 Agent 自报的改进Agent 基于静态推理说现在 80ms却没重测prompt 强制要求重测用git diff 本地重驱动验证跨测量陈旧状态前一轮缓存让修复后测量无意义轮次之间总是拆除 重启必要时清空扩展存储该缓存却重写Agent 重写内层循环而加memoize本可解决Convention 层优先优先缓存/记忆化/防抖而非重写阈值混淆Agent修复了超过阈值但用户无感知的问题阈值是启发式不是教条超阈值 用户可感知 真问题打磨引入性能回归UX 打磨修复加 spinner、加防抖延迟实际增加延迟任何变更集后都重测受影响流程而非只测性能专项变更git 调用频率噪声git 调用随仓库状态变化在热仓库态与全新仓库态各测一次两者都报告无上下文的规范修复给会改变状态的 getter 加memoize破坏正确性Convention 层 Agent 必须验证方法确实是纯函数暂停循环的红旗在没有捕获基线的情况下即将派发修复Agent 报告改进但git diff只有重写、没有测量逻辑基线与修复后测量之间没有拆除 重启修复后测量相对基线在噪声内10%——你只是赢在方差上某条 speculation 连续 3 轮挂着未处理——升级给用户不要悄悄派发即将把规范修复应用到实际上不在热路径上的代码。跳过测量的绊线推理中出现以下任何一句立即停下先测量这显然更快This is obviously faster标准优化模式Standard optimization pattern大家都这么缓存Everyone caches this kind of thing看起来像热路径Looks like a hot path加个 memoize 没坏处Wont hurt to add memoizeAgent 说它改进了Agent said it improvedMeasured 层需要数字Convention 层需要模式匹配——两者都不接受显然。需要抵制的合理化借口借口现实投机性优化经常是对的有时是。但不测量就无法分辨。先归档别凭直觉折腾加缓存从不有害缓存会造成陈旧 bug。每个memoize都是关于身份 失效的决策测一次就够了方差真实存在。3–5 次报告散布Agent 重测了信它的数字用git diff确认重测逻辑真的跑了别信自报跳过拆除更快缓存状态毁基线。10 秒拆除换来的是省下几小时追查幻影回归规范修复显而易见跳过审计审计能暴露相邻的规范违反。既然人已经在同一 PR 里顺手修第二个是免费的这个可能很慢Speculation 层。进 open-questions不派 Agent八、输出物与完成检查每次完整运行产生的产出物.work/live/feature-perf/baseline.md—— 捕获的测量基线每轮迭代.work/live/feature-perf/findings.md—— 按层分类的发现含基线 → 修复后数字.work/live/feature-perf/open-questions.md—— 给用户审阅的投机性条目干净的 working tree针对性提交 / 暂存变更记录实际改进的修复后测量而非一句LGTM。声明live-perf complete前必须逐项确认每个正在处置的指标都有文档化的基线只派发了 Measured Convention 发现——speculation 留在 open-questions修复后测量经过重新驱动 重新采集验证非 Agent 自报对每个 Agent 的工作做过git diff——无静默回归基线与修复后测量之间拆除 重启过已把open-questions.md呈现给用户若从/live-exercise进入退出后已归还控制权变更如有触发父循环继续。九、相关技能与后续衔接/live-perf的强制前置背景是/live-inspect——它提供本流程所有原始 MCP 工具evaluate_in_webview、read_logs、evaluate、read_console的完整参考。相关技能还包括/live-exercise—— 在 Phase 7 调用本技能功能/意图问题先用它/live-pair—— 交互式对等技能遇到这个感觉慢的信号时把工作委托到这里/simplify—— 性能修复后的代码质量清理/deep-review—— 静态正确性追踪能捕获当前负载下未暴露的性能 bug。整体而言/live-perf代表了一种可移植的工程纪律把性能工作从凭直觉改代码变成定义轴 → 采基线 → 分类 → 定向派发 → 重测收敛的可审计闭环。仓库中 .claude/skills/live-perf/SKILL.md 即完整规范而 scripts/mcp-vscode-server.mjs、src/system/rpc/logger.ts、src/webviews/apps/shared/rpc/rpcController.ts 与packages/git-cli/src/providers/__tests__/integration/下的 spawn 计数测试共同构成了这套方法论在 GitLens 中的真实落地底座。赞分享开发工具版本控制【免费下载链接】vscode-gitlensSupercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more项目地址https://gitcode.com/gh_mirrors/vs/vscode-gitlens点击查看免费下载相关推荐ToolJet Queries 查询机制全解Query Panel 的创建、配置、执行与底层实现ToolJet Queries 查询机制全解Query Panel 的创建、配置、执行与底层实现 Queries查询是 ToolJet 应用与数据源之间的开发工具版本控制Sanity Studio 性能追踪体系实战Perf 测试、Bench 基准套件与性能回归防护Sanity Studio 性能追踪体系实战Perf 测试、Bench 基准套件与性能回归防护 Sanity Studio 的性能追踪体系由性能测试PerfCMS前端终极Emscripten性能调优指南从测量到优化的完整工作流终极Emscripten性能调优指南从测量到优化的完整工作流 Emscripten作为将C/C代码编译为WebAssembly的强大工具其性能调优需要系编译器WebAssembly开发工具构建工具上一篇虚拟游戏手柄革命vJoy深度技术解析与实战指南下一篇3分钟掌握DLSS Swapper游戏画质升级的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
