性能调整[英] Performance tuning

问题描述

你好,

我目前正在开发一个使用大量
的应用程序计算能力、磁盘访问和内存缓存(更准确地说:
信息检索平台).在这类应用中
最后剩下的就是性能调优了.

因此,例如,您可以在类似于 ''case/
的情况下执行 ''if then else''switch'', 一个 ''if/then/else'' 并作为与静态的乘法
缓冲.或者,您可以使用内联委托进行排序,使用
委托和静态委托.就原始而言,哪个最好
速度?还是我应该只使用反射器,填写排序并节省时间?
也许我应该将我的关键代码标记为"不安全"?我应该避免吗-
每个?或者更确切地说使用它?"产量"呢?我应该避免异常吗?
什么是真正的性能杀手?等等……

因为我不想测试所有可能的优化和
从而重新发明轮子我想知道其他人是否已经
编写包含所有最佳实践的文档、书籍或文章
关于 C# 中的低级优化.

感谢您的帮助.

谢谢,
Stefan.

推荐答案

使用像样的分析器并找出答案.否则你只是在猜测,
并且可能收效甚微,或者使事情变得更糟.在大多数
在这种情况下,性能并不取决于诸如
之类的微优化if/else vs switch,而是归结为批量算法,例如循环
在一对集合上而不是使用字典来表示"存在"
等等

具体情况;我记得读过一篇文章展示了这个开关
*略微*更快,但几乎没有足够的余量来保证
编辑带来的风险……"不安全"除非你做很少的事
实际上在块内使用不安全的功能.对于排序,
基于接口的方法(IComparer)/可能/比
更快代表 - 但不要相信任何人:安装测试工具并找出答案,
或配置您的应用程序.至于例外 - 好吧,我的代码可以搞砸
如果我没有正确处理错误,事情确实很快就会发生
条件;-p

Marc

稍微跟进一下,性能调优也是一个分阶段的方法.
在深入研究之前,您必须查看全局问题
像您现在所问的微优化.就像马克说的,使用一个
profiler,看看你的应用有哪些瓶颈,然后解决
那些.如果您是性能调优,那么您心中有一个目标
就性能而言,您的应用程序可以接受(如果您不这样做
有了目标,那么为了性能调优而调优就是一个
在这里浪费,因为您很可能会妥协
过程中代码的可维护性和设计).

对于 switch 语句,一旦你有多个案例,C#
编译器将其转换为 Hashtable(可能是 .NET 2.0 中的字典和
超越)这是用于开关.对于非常大的 switch 语句,我的
猜测是这样更快.另外,这应该比重复要快
if/then 语句也是如此.

我同意 unsafe 在这里对你有很大的帮助.

IIRC,调用代表的速度大大提高了
..NET 2.0.调用接口/类实例总是会
更快,但我认为调用代表可能更接近速度
直接调用成员.当然,如果你是通过一个
大量的迭代,这少量可以加起来.

使用"收益"总是会增加开销.当您使用"产量"时对于
一个 IEnumerable 实现,编译器正在生成一个状态机
在后台为您服务,而这总是会花费更多资源
不如自己动手.

希望这会有所帮助.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"马克·格拉维尔"<ma**********@gmail.com 在留言中写道
新闻:开**************@TK2MSFTNGP04.phx.gbl...
使用一个像样的分析器并找出答案.否则你只是在猜测,并且
可能收效甚微,或者使事情变得更糟.在大多数情况下,
性能并不取决于微优化,例如 if/else vs switch,
而是归结为批量算法,例如循环遍历一对集合
而不是使用字典来表示"存在";等等

具体情况;我记得读过一篇文章证明 switch 是
*略微*更快,但几乎没有足够的余量来保证风险
来自编辑......"不安全"除非您实际使用
,否则将做的很少块内的不安全功能.对于排序,基于接口
方法(IComparer<T>)/可能/比委托更快 - 但不要相信
任何人:安装测试工具并找出或分析您的应用程序.至于
例外 - 好吧,如果我
,我的代码确实可以很快搞砸没有正确处理错误情况;-p

马克


感谢您的反应.他们确实有帮助.

我确实想清理一些东西.我们与 ANTS 分析器合作
在这里,这当然有助于确定瓶颈.我们已经
对算法实施启发式以加快速度;甚至
实现了一个自定义压缩组件来加速磁盘写入.
尝试了不同的算法来匹配,确定哪个
启发式算法在哪种情况下最好.但是当你
每个 cpu 执行一些算法操作数百万次,
然后进行微优化.

当然为了优化而优化当然永远不会
一个好主意...除非你处于你正在做的位置
类似谷歌的系统,减少服务器的存在是值得的
周围(权衡是生成的应用程序
不应该变得不稳定,这是我们不使用 C+ 的主要原因
+)...嗯,嗯,是的,这正是我们正在做的.这么说吧
直言在大局范围内:目标是成本
减少.在我们的例子中,它指定了"大图".相当
很清楚.

关于可维护性:我们在这里说的是地狱,当然是地狱
代表"高效低级";代码.不应该是
可维护的;这就是我们有非优化版本的原因.如果是
停止工作,我们将把它扔掉并从非
优化版本,吸取教训(但那是
这些特定的代码段不太可能).我明明想指出
我们不只是优化每一行代码并承认
关于可维护性和设计的问题.

我已经在这些反应中看到了很多好的信息.我是
对大量(浮点)操作特别感兴趣
在数组(结构)上 - 像排序,但也像过滤,数组
调整大小,用基于其他的计算填充这些数组
数组等 - 以及处理此问题的方法.我主要使用
这些结构中的基本类型"long"和"double";哪里用了long
因为 32 位不够大.我也对开销感兴趣
由继承引起的;特别是如果与泛型组合构成姿势
额外的开销.

我觉得 switch 使用字典很有趣,因为我预计会跳转-
按价值.也许我应该深入研究一下 IL...

谢谢,
斯特凡.

5 月 9 日下午 3:09,"Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com 写道:
稍微跟进一下,性能调优也是一个分阶段的方法.
在深入研究之前,您必须查看全局问题
像您现在所问的微优化.就像马克说的,使用一个
profiler,看看你的应用有哪些瓶颈,然后解决
那些.如果您是性能调优,那么您心中有一个目标
就性能而言,您的应用程序可以接受(如果您不这样做
有了目标,那么为了性能调优而调优就是一个
在这里浪费,因为您很可能会妥协
过程中代码的可维护性和设计).

对于 switch 语句,一旦你有多个案例,C#
编译器将其转换为 Hashtable(可能是 .NET 2.0 中的字典和
超越)这是用于开关.对于非常大的 switch 语句,我的
猜测是这样更快.另外,这应该比重复要快
if/then 语句也是如此.

我同意 unsafe 在这里会为你做很多事情.

IIRC,调用代表的速度大大提高了
.NET 2.0.调用接口/类实例总是会
更快,但我认为调用代表可能更接近速度
直接调用成员.当然,如果你是通过一个
大量的迭代,这少量可以加起来.

使用"收益"总是会增加开销.当您使用"产量"时对于
一个 IEnumerable 实现,编译器正在生成一个状态机
在后台为您服务,而这总是会花费更多资源
不如自己动手.

希望这会有所帮助.

--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com

"马克·格拉维尔"<marc.grav...@gmail.com 在留言中写道

新闻:开**************@TK2MSFTNGP04.phx.gbl...
使用一个像样的分析器并找出答案.否则你只是在猜测,并且
可能收效甚微,或者使事情变得更糟.在大多数情况下,
性能并不取决于微优化,例如 if/else vs switch,
而是归结为批量算法,例如循环遍历一对集合
而不是使用字典来表示"存在";等等.
具体情况;我记得读过一篇文章证明 switch 是
*略微*更快,但几乎没有足够的余量来保证风险
来自编辑......"不安全"除非您实际使用
,否则将做的很少块内的不安全功能.对于排序,基于接口
方法(IComparer<T>)/可能/比委托更快 - 但不要相信
任何人:安装测试工具并找出或分析您的应用程序.至于
例外 - 好吧,如果我
,我的代码确实可以很快搞砸没有正确处理错误情况;-p
马克


本文地址:https://www.itbaoku.cn/post/1050454.html