关于c＃：当操作是O（1）时，是否值得缓存.Count（或.Count（））的结果？

Is it worth caching the result of .Count (or .Count()) when the operation is O(1)?

如果.count或.count()在实现ICollection的对象上多次使用(因此具有O(1)计算复杂性，除非它被重写)，那么在性能方面(而不是内存方面)更好吗？即使存在非常小的差异，在临时变量中缓存值而不是每次访问属性值需要吗？

相关讨论

这是一个反问句还是一个哲学问题？
ICollection对象几乎总是将计数本身缓存在backing字段中，count返回该字段。
@aresavatar：对于每个实现ICollection并缓存其计数的对象，我可以创建一个实现ICollection且不缓存其计数的对象，并且我可以使检索计数的速度非常缓慢。你关于"几乎总是缓存计数"的说法是错误的。
前传：在.NET中，最好调用.count()还是在可用时调用.count？
@杰森-是的，你可以，这就是为什么我说"几乎总是"。但是这是一个写得很糟糕的类，它的性能非常差，所以您可能不会。
@阿雷萨瓦塔：不，如果我能为每一个没有邪恶的人制造一个邪恶的人，那么邪恶的人至少和没有邪恶的人一样多。同样，这使得"几乎总是"的说法是错误的。
@杰森-你完全错了。一个人可以在代码中做很多坏事。这并不意味着有人会这样做，即使有人这样做，他们的代码也会因为工作不好而被丢弃。
@阿雷萨瓦塔：请指出我说的一个特别的"完全错误"的说法。谢谢！
@杰森："如果我能为每一个不邪恶的人制造一个邪恶的人，那么邪恶的人至少和不邪恶的人一样多。"这句话暗示你写坏代码的能力意味着坏集合至少和好集合一样多，这是完全错误的。大多数编码员不会写这样一个邪恶的收集，即使你也不会。至少我希望如此！所以你认为像善的藏品一样多的邪恶藏品的说法是完全错误的。
@又一次，你不明白。这与写坏代码无关。仅仅因为我给出的示例从来没有人在生产代码中编写或使用过，并不意味着没有任何集合的ICollection不是O(1)。你真的很难理解吗？
@Jason-一个人不会浪费时间或精力，也不会为所有可能出现的错误代码编写不必要的防御代码。你很难理解吗？
@杰森，让我们在聊天中继续讨论。
@阿雷萨瓦塔：我知道，这就是为什么我在回答中说，除非我知道我可能会进入邪恶的收藏，否则我不会担心这个问题，我发现这是一个重要的性能瓶颈。(原版加粗)。我还说：只需编写最简单的有效代码(使用ICollection.Count)。如果并且只有当它是应用程序中的性能瓶颈时，我才会担心对它进行调优。
为什么投反对票？

直接回答这个问题，即使是O(1)操作也需要很长时间才能完成；只是，无论收集的数据有多大，它总是需要相同的时间。缓存结果并将其读回将是快速的，总是，但不能保证比任何给定的O(1)操作都快。你首先需要一些时间安排；)

是的，它可能(非常轻微)更快，因为方法调用的开销、相关的错误检查以及(在count()的情况下)iCollection的动态类型检查都有一定的开销。

但是值得吗？这完全取决于您和您的应用程序。如果你处于一个非常紧密的内部循环中，这可能是值得的。然后，在最近的.NET运行时上，在这种情况下，这种琐碎的属性可能会被内联。

和往常一样，让分析器告诉您应用程序中的热点在哪里。

对不起，认为ICollection.Count是O(1)是错误的。这在道义上应该是，但不能保证它是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public EvilCollection<T> : ICollection<T> {
private readonly ICollection<T> collection;
private readonly Func<int, int> slowGrowingFunction;
public EvilCollection(
ICollection<T> collection,
Func<int, int> slowGrowingFunction)
{
this.collection = collection;
this.slowGrowingFunction = slowGrowingFunction;
}

public int Count {
get {
Thread.Sleep(1000 * this.slowGrowingFunction(this.collection.Count));
return this.collection.Count;
}
}

// other methods wrap methods on collection for ICollection<T>
}

ICollection<T> evilCollection =
new EvilCollection<T>(collection, n => Ackermann(4, n));

哦，不，evilCollection.Count是O(Ackermann(4, n))！

这就是说，除非我知道我可能加入了邪恶的集合，否则我不会担心这个问题，而且我发现它是一个重要的性能瓶颈。请记住，代码不太清楚，可能不太正确(缓存结果后，计数更新是什么？)等。

只需编写最简单有效的代码(使用ICollection.Count)。如果并且只有当它是应用程序中的性能瓶颈时，我才会担心对它进行调优。