Green Hills MULTI用久了变卡，往往不是单一原因，而是工程放置位置、索引扫描范围、构建派发、调试连接模式一起叠加出来的体感问题。处理思路可以更务实一点：先把卡顿点定位到编辑浏览、构建、调试三类动作之一，再把索引与缓存落到本地高速盘，并用一次可回滚的重建流程把“越用越慢”的状态拉回到可控。

　　一、Green Hills MULTI卡顿怎么办

　　先别急着重装，卡顿要先分清是界面交互慢、构建慢，还是调试视图刷新慢，不同卡法对应的入口完全不一样。

　　1、先把卡顿动作固定成可复现的一步

　　用同一台机器、同一个工程，反复执行一个动作来复现卡顿，比如展开工程树、全局跳转一次引用、点击一次构建、打开一次调试连接，先把问题从“感觉慢”变成“某一步慢”，后面的优化才有方向。

　　2、把工程与输出从网络盘挪到本地盘再观察一次

　　如果工程目录或构建输出在网络共享盘，索引读写与小文件创建会被放大拖慢，优先把工程目录复制到本地SSD，再用同样动作复测，确认卡顿是否明显缓解。

　　3、构建卡顿先检查并行构建是否真正跑起来

　　MULTI的Builder会做依赖分析并尽可能并行编译来利用多核资源，如果你看到CPU长期低占用但构建很慢，优先排查并行派发是否被限制。

　　4、从工程文件入口打开构建参数做一次“限流与放行”

　　在工程窗口选中顶层.gpj文件，鼠标右键点击【Build Options】进入构建选项窗口，先检查是否存在把并行作业数压得很低的配置，再把作业数调整到与本机核心数接近的水平后重跑构建。

　　5、用一次完整重建排除“增量状态脏了”带来的假卡顿

　　在工程窗口选中目标构建项，点击菜单【Build】选择【Rebuild】触发全量重建，观察卡顿是否只发生在增量阶段，若全量反而稳定，说明你更该清理索引与派生文件而不是继续改编译参数。

　　6、调试视图很慢时先确认是否处在会禁用缓存的连接模式

　　如果你在调试时看寄存器、内存窗口刷新变慢，先检查连接方式是否启用了Low-intrusion这类会关闭MULTI缓存的模式，因为该模式会禁用缓存从而影响读取与刷新体验。

　　7、用连接管理入口统一检查连接方法配置

　　点击菜单【Connect】选择【Connection Organizer】进入连接管理器，定位当前工程使用的Connection Method，优先把排查动作放在“是否启用低侵入模式”“是否存在异常轮询刷新”等连接侧选项上，再回到调试窗口复测。

　　二、Green Hills MULTI索引与缓存怎么优化

　　索引与缓存的目标不是越多越好，而是让常用的代码浏览与跳转动作保持顺滑，同时避免把大量无关目录也纳入扫描，导致每次打开工程都要做一轮大规模读写。

　　1、先确认你慢的是否是代码浏览与引用跳转这一类动作

　　在编辑区对函数或变量执行浏览动作时，MULTI会提供诸如Browse References一类能力，如果这一步卡顿明显，基本可以把优化重点放在索引规模与索引落盘位置上。

　　2、把索引与缓存的读写从“分散在各处”变成“集中在本地高速盘”

　　新建或迁移工程时，尽量把工程根目录与构建输出目录都放在本地SSD下的固定工作区，避免工程散落在多块盘符或网络路径里，索引与缓存读写越集中，卡顿越不容易被放大。

　　3、用“缩小扫描面”的方式控制索引体量

　　把第三方依赖、镜像出来的SDK目录、自动生成的大目录从日常浏览路径里隔离出去，只把你真正需要频繁跳转的业务代码作为主要索引目标，这样即使工程总量很大，日常交互也不会被无关文件拖累。

　　4、在你确定要“重建索引”时，用重建替代反复增量修修补补

　　当你遇到跳转失准、引用列表异常、打开工程越来越慢时，不要靠反复小改小建硬扛，优先用【Build】里的【Rebuild】把派生物整体重算一遍，再看索引型卡顿是否同步消失。

　　5、调试侧缓存要按场景取舍

　　做板级Bring-up或需要尽量少干扰目标系统时，低侵入模式会关闭缓存以降低影响，但如果你是在做常规应用调试、频繁查看内存与变量，建议避免长期处在会禁用缓存的模式里，否则卡顿更容易出现。

　　6、把构建并行与索引重算的时间错开

　　索引重建和全量构建都属于高IO高CPU动作，尽量不要在同一时间段叠加执行，尤其是笔记本在电源策略限制下更容易出现界面卡顿，建议先完成一次索引重建，再单独跑全量构建做验证。

　　三、Green Hills MULTI卡顿索引缓存联动排查

　　当你不确定是索引、缓存还是连接方式导致卡顿时，可以用一套“先隔离再恢复”的顺序，把问题快速压缩到一个可操作点，避免在多个方向同时改动导致越改越乱。

　　1、先做一次工作区隔离验证

　　把工程复制到本地SSD的新目录，用新目录重新打开工程并执行同一条复现动作，如果卡顿明显缓解，优先把根因锁定在路径与IO上，再回头处理网络盘、杀毒扫描、同步盘占用等外部因素。

　　2、再做一次构建链路的强制重算

　　在新工作区里点击【Build】选择【Rebuild】跑一轮全量重建，观察卡顿是否主要发生在增量阶段还是全量阶段，用结果判断你该清缓存派生物还是该调并行与依赖。

　　3、把调试连接配置单独拉出来核对

　　点击【Connect】进入【Connection Organizer】，只做连接方法相关核对与切换，不要同时改工程结构，重点看是否启用了会禁用缓存的模式，再回到调试窗口看刷新速度变化。

　　4、最后再回到工程级选项做“少量可回滚”的调整

　　选中.gpj右键点【Build Options】，一次只改一个点，比如并行作业数或某个明显的重负载选项，改完就复测并记录效果，确保每一步都能回滚到上一个稳定状态。

　　5、把稳定后的配置固化成团队口径

　　当你确认卡顿主要由路径、索引范围、连接模式中的某一项引起后，把工程放置规则、本地工作区结构、连接方法选择与重建动作写成团队操作口径，避免换机器或换成员后又回到同样的卡顿循环。

　　总结

　　Green Hills MULTI卡顿处理要先定位卡在编辑浏览、构建还是调试，再把工程与索引缓存落在本地高速盘并缩小索引扫描面；构建侧用.gpj的【Build Options】校正并行派发并配合【Build】的【Rebuild】做一次干净重算；调试侧重点检查连接方式是否启用了会禁用缓存的低侵入模式，并通过【Connect】下的【Connection Organizer】统一核对连接配置，通常就能把“越用越慢”的状态拉回到稳定区间。