如何找到 IntelliJ Kotlin lint 检查背后的原因

Question

我在使用 IntelliJ 作为 IDE 编写 Kotlin 时收到一条 lint 消息：The argument can be converted to 'Set' to improve performance

我的代码是这样的：

val variable3 = variable1 - variable2变量是类型List<Int>

linter 建议我将其更改为val variable3 = variable1 - variable2.toSet()

我想知道为什么它建议进行此更改以及文档在哪里，以便下次我可以查找消息并了解 lint 检查背后的原因。

Answer 1

这是关于性能和效率 \xe2\x80\x94 特别是，随着数据变大，性能如何扩展。

\n

该-运算符调用标准库的Iterable<T>.minus(elements: Iterable<T>)扩展函数。\xe2\x80\x82如果您查看其代码（可以在 IntelliJ 中执行此操作），您会发现它通过获取第一个可迭代对象来工作（variable1在本例中）并对其进行过滤以仅保留不在第二个值中的值( variable2)。

\n

它如何检查一个元素是否在第二个元素中？\xe2\x80\x82通过调用它的contains()方法。\xe2\x80\x82但是它如何工作将取决于可迭代的类型。\xe2\x80\x82Most Sets，例如，可以通过哈希码查找，无论集合有多大，都需要很短的时间。

\n

然而，大多数Lists 和其他可迭代对象无法做到这一点：它们需要逐个元素搜索整个列表。\xe2\x80\x82这需要多长时间显然取决于列表 \xe2\x80\ 的大小x94 对于短列表来说它会非常快，但是搜索具有数千或数百万元素的列表可能需要一些时间。

\n

在这种情况下，它特别重要的是，它必须重复执行搜索：对第一个元素的每个元素进行一次搜索。\xe2\x80\x82，因此时间确实会增加。

\n

假设第一个 iterable 有元素，第二个 iterable 有 .\xe2\x80\x82 减法必须进行检查；如果第二个是一组，那么每次检查花费的时间大约相同，所以总体时间与 成正比。\xe2\x80\x82 但如果不是，那么每次检查花费的时间与 成正比，所以总体时间是 \xc3 \x97 \xe2\x80\x94 可以很快变得非常大！\xe2\x80\x82（例如，如果你让每个列表变大 10\xc3\x97，则需要 100\xc3\x97 一样长.)

\n

因此，如果您不希望程序在开始处理更多数据时陷入停顿，那么首先将第二个列表转换为集合是非常值得的。\xe2\x80\x82对于少量数据，它会添加一个很少的额外工作，但这可能不会被注意到；对于大量数据来说，这可能是一个巨大的胜利。

\n

这就是 IntelliJ 检查建议这样做的原因。

\n\n

^{（对于那些了解算法复杂性的人，请原谅我在这里所做的简化:)}

\n\n

有趣的是，当我自己尝试时（在 IntelliJ 2021.2.3 中使用 Kotlin v1.5.73），它并没有提出这个建议。\xe2\x80\x82并且查看标准库的实现，我发现在某些情况下该minus()方法将为您进行转换！\xe2\x80\x82但是，我认为它不涵盖其他一些常见情况，因此如果您认为列表可能会变大，仍然值得自己进行转换。

\n

Answer 2

您可以将鼠标悬停在文档上并打开文档，如下所示：

一般的快速修复选项可以在设置 -> 检查 -> kotlin 下找到并打开/关闭（示例）