性能提升 - 更快的代码补全

随着 Java Language Server 最近 1.0版本的发布，我们对代码补全的性能进行了重大的改进。下图比较了最近几个版本之间的代码补全响应时间。对于补全类型、构造函数名等常见的场景，代码补全性能较之前版本（ v0.80 、 v0.81 、 v.0.82 ）有显著的提升

性能改进总览

代码补全引擎由三个阶段组成：

阶段一 (P1) 搜索索引器以查找建议
阶段二 (P2) 转换建议为补全信息
阶段三 (P3) 计算代码片段建议

根据我们的分析，我们发现所有三个阶段都有改进的空间。下表显示了我们在过去版本中所做的改进。我们将在下一节中更多地讨论这些变化的细节。

	0.80.0	0.81.0	0.82.0	1.0.0
减少 Windows I/O 操作 (P2)	N/A
对常量 /默认值进行优化(P2)	N/A
延迟解析通用代码片段(P3)	N/A	N/A
优化匿名构造函数(P2)	N/A	N/A	N/A
JDT 搜索引擎优化 unit.complete()(P1)	N/A	N/A	N/A
JDT 搜索引擎改进索引文件的 I/O 操作(P1)	N/A	N/A	N/A
延迟 TextEdit 计算 (P2)		N/A	N/A	计划中

关键改动细节

版本 0.81.0 减少 Windows I/O 操作. #1831

在过去的性能测试中，我们发现很大一部分时间成本花在了计算文件 URI 上面。这个发现佐证了我们之前的观察：由于 JVM 中特定于平台的文件系统相关实现，Windows 平台上的代码补全性能相对较差。通过删除不必要的 URI 计算，我们提高了性能，尤其是在 Windows 平台上。

版本 0.81.0 对常量 / 默认值进行优化. #1835

当我们完成一个常量字段（例如 Constants.*）时，完成弹出窗口将在选择列表中显示建议的字段名称及其常量值（例如 Bit1 : int = 1 ）。我们的分析发现，当类包含大量常量字段成员时，这会让补全非常慢。这是因为我们从 AST Tree 计算字段值，这在操作大文件时开销很大。

为了优化它，我们决定推迟解析常量值。代码补全会简化建议标签并仅显示字段名称（例如 Bit1 :int ）。当您将鼠标悬停在 Javadoc 的完成项上时，才会在 Javadoc 部分显示它的常量值。

以下是一个拥有 1400 多行和 150 多个常量字段的类的字段完成的性能比较。

版本	平均响应时间（毫秒）
0.80.0	1429ms
0.81.0	72ms

版本 0.82.0 延迟解析通用代码片段 Delay resolving generic snippets. #1838

有两种类型的代码段：

通用片段（例如 foreach 、fori 、ifelse 等）
类型定义片段（例如类、接口等）

对于通用代码段，它会在构建完成项的"TextEdit"之前评估具有给定上下文的模板，此类评估可能会很昂贵。现在我们将这类评估推迟到解决阶段。当代码补全完成项被建立完成之后，模板模式将作为占位符填充。实际值在解决阶段进行评估，这不会阻止完成项目的显示。这也是一项关于"延迟解析 TextEdit"可以在多大程度上提高性能的实验，并且在大多数情况下，它应该运行良好

版本 0.82.0 优化匿名构造函数 Optimize for anonymous constructors. #1836

当我们想完成一个新的 Runnable 时, 期望的结果是这样的:

Runnable() {}

它由两部分组成

Runnable 名称
空白的 body 片段 body () {\n\t\n}

通过性能分析，我们发现 CodeFormatUtil.format 花费了大量时间。

为了有一个正确的缩进和行分隔符，它们被格式化为当前的首选项。格式化是昂贵的，并且为所有项目（有时多达数千）重复格式化相同的内容（空体）。为了改进它，我们将空体格式化进行了一次性的操作并在所有项目中重用它。

版本 1.0.0 提升代码补全搜索速度

为了优化索引搜索性能，我们做了两个关键改动。

使索引搜索任务更高效. #1846, #575562

我们的性能分析显示，索引查询任务 97% 的 CPU 时间用于从磁盘加载索引内容的 I/O 操作。这是因为我们使用的索引机制倾向于节省内存并且在搜索引擎中使用很少的缓存。几乎每个查询都必须从磁盘重新加载索引内容。一种直接的优化是降低 I/O 的频率。

Java 索引器由多个哈希表组成，每个哈希表用于记录某种类型的代码部分，例如类型声明、方法声明、引用、方法引用等。典型的查询作业从索引中读取一个或多个哈希表，然后连接这些将条目索引到目标结果中。

当我们完成类型 /构造函数名称（例如 Str 或者 new Str ）时，索引查询作业读取两个哈希表，一个是用于查找匹配类型名称的 typeDecl 表，另一个是用于查找类文件路径的 documentName 表声明相应的类型。由于我们的目的只是完成类型名称并自动导入对应的 package ，因此 typeDecl 表足以满足我们的要求，并且不需要类文件路径。我们的优化是只读取 typeDecl 索引表，结果证明少读取一张索引表可以节省大量 I/O 成本。