猿问

优化C#/.NET程序的技巧

优化C#/.NET程序的技巧

现在看来,优化是一门丢失的艺术。难道不是有一段时间,所有的程序员都在压缩他们的代码的每一盎司的效率吗?在雪中行走五英里时经常这样做?

本着找回失去的艺术的精神,对于简单的(或者可能是复杂的)更改来优化C#/.NET代码,您知道哪些技巧?因为这是一件非常广泛的事情,这取决于一个人想要完成什么,这将有助于为你的技巧提供背景。例如:

  • 将多个字符串连接在一起时,请使用

    StringBuilder

    相反。请参阅底部的链接,以了解对此的注意事项。
  • 使用

    string.Compare

    比较两个字符串而不是执行类似的操作

    string1.ToLower() == string2.ToLower()

到目前为止,普遍的共识似乎是衡量的关键。这种情况忽略了要点:测量并不能告诉你哪里出了问题,或者如果你遇到瓶颈该怎么办。我曾经遇到过字符串连接瓶颈,不知道该怎么办,所以这些技巧是有用的。

我甚至发布这篇文章的目的是要为常见的瓶颈提供一个位置,以及在遇到这些瓶颈之前如何避免这些瓶颈。任何人都不一定要盲目地遵循即插即用代码,而是要更多地理解,至少在某种程度上,应该考虑性能,还有一些常见的缺陷需要注意。

不过,我可以看出,知道小费为什么有用,以及应该在哪里应用,也可能是有用的。为StringBuilder提示我找到了我很久以前做过的帮助在乔恩·斯基特的网站上.


有只小跳蛙
浏览 538回答 3
3回答

森栏

现在看来,优化是一门丢失的艺术。曾经有一天,显微镜的制造被当作一门艺术来实践。人们对光学原理知之甚少。零件没有标准化。管子、齿轮和镜片必须由高技能的工人手工制作。如今,显微镜是作为一门工程学科而产生的。物理的基本原理是非常清楚的,现成的零件是广泛可用的,显微镜制造工程师可以作出明智的选择,如何优化他们的仪器来完成它设计的任务。表现分析是一种“失传的艺术”,是一件非常好的事情。那门艺术是被实践的作为一种艺术..应该根据实际情况进行优化:工程问题可通过仔细应用固体工程原理来解决。多年来,我多次被问及我的“技巧和技巧”清单,人们可以用这些方法来优化VBScript/jscript/他们的活动服务器页面/他们的VB/他们的C#代码。我总是抗拒这个。强调“技巧和技巧”是完全错误的方式来接近性能。这种方式导致的代码很难理解,很难推理,很难维护,这通常不会比相应的直接代码更快。处理性能的正确方法是将其作为一个工程问题来处理,就像任何其他问题一样:设定有意义的、可衡量的、以客户为中心的目标.构建测试套件,在现实但可控制和可重复的条件下对照这些目标测试您的性能。如果这些套件显示你没有达到你的目标,那么就使用一些工具,比如分析器来找出原因。优化剖析器所确定的最糟糕的子系统。保持对每个更改的分析,以便清楚地了解每个更改对性能的影响。重复三件事中的一件,直到有一件事情发生:(1)你达到了目标,然后把软件发送出去;(2)你把目标向下修正到你能达到的目标;或者(3)你的项目被取消了,因为你无法达到你的目标。这和你解决任何其他工程问题是一样的,比如为这个特性添加一个功能设定的客户目标,跟踪在实现方面的进展,通过仔细的调试分析修复问题,一直迭代直到你发布或失败。性能是一个特点。对复杂的现代系统的性能分析需要纪律和专注于坚实的工程原理,而不是一个小范围适用于琐碎或不现实情况的技巧包。我从来没有通过应用技巧和技巧来解决现实世界的性能问题。

拉风的咖菲猫

找个好的侧写员。即使没有一个好的分析器,也不要费心去优化C#(真的,任何代码)。实际上,手头有一个采样和一个跟踪分析器非常有帮助。如果没有一个好的分析器,您可能会创建错误的优化,最重要的是,优化那些从一开始就不是性能问题的例程。轮廓的前三个步骤应该是:(1)度量,(2)度量,然后(3)度量.

慕尼黑5688855

优化准则:除非你需要,否则不要这样做。如果用新硬件代替开发人员来解决问题更便宜,就不要这么做不要这样做,除非您可以测量生产等效环境中的变化。除非你知道如何使用CPU,否则不要这么做。和内存分析器如果这样做会使您的代码不可读或无法维护,请不要这样做。由于处理器的速度越来越快,大多数应用程序的主要瓶颈不是CPU,而是带宽:片外内存带宽、磁盘带宽和网络带宽。从远端开始:使用YSlow来了解为什么您的网站对于最终用户来说是缓慢的,然后向后移动并修复您的数据库访问不太宽(列)和不太深(行)。在非常罕见的情况下,为优化CPU使用做任何事情都是值得的,请注意不要对内存使用产生负面影响:我看到了“优化”,开发人员试图使用内存来缓存结果以节省CPU周期。净效果是减少可用内存来缓存页面和数据库结果,这使得应用程序运行速度慢得多!(见关于测量的规则。)我也看到过这样的情况:一种“愚蠢”的非优化算法击败了“聪明”优化算法。千万不要低估编译器编写人员和芯片设计者在将“低效”循环代码转化为超级高效代码方面的作用,这些代码完全可以在芯片上的内存中通过流水线方式运行。你的“聪明”的基于树的算法有一个未包装的内循环反算,你认为它是“有效的”,它可以被击败,仅仅是因为它在执行过程中没有停留在芯片上的内存中。(见关于测量的规则。)
随时随地看视频慕课网APP
我要回答