我正在使用一个使用从System.Collections.CollectionBase
派生的集合的框架。用户一直在抱怨性能,我觉得这些使用频繁的集合可能是问题的重要组成部分。有没有办法使用工具或探查器或在IL中我可以获得有关装箱/拆箱处罚的一些指标?我需要证据来支持System.Collections.Generic
的推送。我已经尝试过CLRProfiler,但往往会迷路而且不确定我应该寻找什么。
更新
感谢所有您的投入到目前为止。我知道这可能不是主要的瓶颈,但我正在寻找尽可能多的性能杀手的指标。这只是其中之一,不确定它有多大,因此寻找一种衡量它的方法。
答案 0 :(得分:10)
虽然我当然鼓励您从非通用集合迁移到通用集合,但出于充分的理由,我真的怀疑这些集合可能是导致性能问题的原因。当你达到微观水平时,拳击通常只是一个问题,需要在高性能情况下挤出微小的收益。一般来说,出于GC的原因,也可以避免这种情况,但在这个领域它通常也很小。
换句话说:拳击会导致用户注意到的性能问题,这是非常值得怀疑的。
显然,我是在概括地说。在不了解您的具体情况的情况下,我无法确切地说出这么多。
修改:请注意,虽然我怀疑您的问题可能是您使用非通用集合本身,但我会指出它是< / strong>非常重要的是用于解决给定问题的集合的类型,尤其是当集合中的数据量很大时。以下是几个例子:
Dictionary<TKey, TValue>
等哈希表将显着优于List<T>
。HashSet<T>
将具有卓越的性能。Queue<T>
将具有卓越的性能。LinkedList<T>
将具有卓越的性能。这些集合应该是任何.NET开发人员(实际上,任何开发人员的)工具集的一部分。如果您发现自己在使用List<T>
(或ArrayList
)或类似数据结构的任何地方使用了项目集合,那么可能会导致性能问题 - 再次,特别是当你的收藏很大。这些都不是我所说的琐碎的性能提升。因此,请注意为您的收藏类型做出明智的选择。
但我推荐一般性能分析器,例如ANTS(好的,但不是免费的)或EQATEC(也好的和免费)。只需在其中一个程序下运行您的应用程序,并查看您的瓶颈所在。我的猜测是,你会发现它不是你的非通用集合;但很自然,我可能是错的。
答案 1 :(得分:2)
为什么不设置一个快速控制台应用来测量各种操作的速度。你可以使用这样一个简单的方法:
private TimeSpan TimedAction(Action action)
{
var timer = new Stopwatch();
timer.Start();
action.Invoke();
timer.Stop();
return timer.Elapsed;
}
并称之为:
var elapsed = TimedAction(() =>
{
//Do some stuff with your collection here
});
Console.WriteLine("Elapsed Time: {0}", elapsed.TotalMilliseconds);
您应该能够从中收集足够的经验证据,以确定哪些集合在类似操作下会更快。项目数量,执行的连续操作数量等......
然而,如上所述Dan;当与数据访问和网络延迟并置时,花在第三方集合上的整体性能可能是微不足道的。
答案 2 :(得分:1)
以下是您需要的证明。
来自MSDN:
除了类型安全,通用 集合类型通常执行 更适合存储和操作 值类型因为没有必要 列入值类型。
请注意,尽管在现实生活中,仿制药实际上并不像微软所说的那么快。差异可以忽略不计。
答案 3 :(得分:1)
在类似的情况下,我发现自己经常做的是this technique,你可以在任何IDE下做。
所以我知道你想要测量一个特定的东西,但总的来说,你最关心的是在任何地方发现性能问题,对吗?
我们对这些问题进行过辩论,但是真正花费时间的程序与此无关。比如在地下图书馆深入30层,就像从资源中提取字符串一样,这样就可以将它们翻译成不同的语言,而事实上它们并不需要。像某人这样的东西将属性设置为True,它会引发一系列通知,其中包含从列表中添加或删除的内容,更新树视图控件,创建和销毁窗口,添加/删除选项卡和菜单项等等。不久之后,该属性再次被设置为False,好像这没什么大不了的。比如在网格控制中设置单元格,其中会出现类似的波浪。 一般来说,尾巴会摇尾巴。
这就是我对真正正在发生的事情的意思。当拳击等问题出现时,样本会显示出来。