There are some things you should do like use generics instead of objects to avoid boxing/unboxing and also improve the code safety, but the best way to optimize your code is to use a profiler to determine which parts of your code are slow. There are many great profilers for .NET code available and they can help determine the bottlenecks in your programs.
Generally you shouldn't concern yourself with small ways to improve code efficiency, but instead when you are done coding, then profile it to find the bottlenecks.
A good profiler will tell you stats like how many times a function was executed, what the average running time was for a function, what the peak running time was for a function, what the total running time was for a function, etc. Some profilers will even draw graphs for you so you can visually see which parts of the program are the biggest bottleneck and you can drill down into the sub function calls.
Without profiling you will most likely be wrong about which part of your program is slow.
An example of a great and free profiler for .NET is the EQATEC Profiler.
The single most important thing regarding this question is: Don't optimize prematurely!
There is only one good time to optimize and that is when there are performance constraints that your current working implementation cannot fulfill. Then you should get out a profiler and check which parts of your code are slow and how you can fix them.
Thinking about optimization while coding the first version is mostly wasted time and effort.
"I would rather choose fast-executing dirty code over something which might be more elegant or clean, but slower."
If I were writing a pixel renderer for a game, perhaps I'd consider doing this - however, when responding to a user's click on a button, for example, I'd always favour the slower, elegant approach over quick-and-dirty (unless slow > a few seconds, when I might reconsider).
I have to agree with the other posts - profile to determine where your slow points are and then deal with those. Writing optimal code from the outset is more trouble than its worth, you'll usually find that what you think will be slow will be just fine and the real slow areas will surprise you.
IMO it's the same for all programming platforms / languages, you have to use profiler and see whitch part of the code are slow, and then do optimization on that parts.
While these links that you provided are valuable insig don't do such things in advance, measure first and then optimize.
There are lots of tricks, but if that's what you're thinking you need, you need to start over. The secret of performance in any language is not in coding techniques, it is in finding what to optimize.
To make an analogy, if you're a police detective, and you want to put robbers in jail, the heart of your business is not about different kinds of jails. It is about finding the robbers.
I rely on a purely manual method of profiling. This is an example of finding a series of points to optimize, resulting in a speedup multiple of 43 times.
If you do this on an existing application, you are likely to discover that the main cause of slow performance is overblown data structure design, resulting in an excess of notification-style consistency maintenance, characterized by an excessively bushy call tree. You need to find the calls in the call tree that cost a lot and that you can prune.
Having done that, you may realize that a way of designing software that uses the bare minimum of data structure and abstractions will run faster to begin with.
If you've profiled your code, and found it to be lacking swiftness, then there are some micro-optimizations you can sometimes use. Here's a short list.
Micro-optimize judiciously - it's like the mirror from Harry Potter: if you're not careful you'll spend all your time there and get nothing else done without getting a lot in return.
The StringBuilder and exception throwing examples are good ones - those are mistakes I used to make which sometimes added seconds to a function execution. When profiling, I find I personally use up a lot of cycles simply finding things. In that case, I cache frequently accessed objects using a hashtable (or a dictionary).
良好的程序架构可以为您提供比优化功能更好的优化。 最优化的是避免运行时代码中的所有 if else，将它们全部放在初始化时。 总的来说，优化不是一个好主意，因为最有价值的是可读的程序，而不是快速的程序。
Good program architecture give you a lot better optimization, than optimized function. The most optimization is to avoiding all if else in runtime code, put them all at initialize time. Overall, optimization is bad idea, because the most valuable is readable program, not a fast program.
发布评论
评论（9）
您应该做一些事情，例如使用泛型而不是对象来避免装箱/拆箱并提高代码安全性，但优化代码的最佳方法是使用探查器来确定代码的哪些部分速度较慢。有许多优秀的 .NET 代码分析器可用，它们可以帮助确定程序中的瓶颈。
一般来说，您不应该关注提高代码效率的小方法，而是在完成编码后对其进行分析以查找瓶颈。
一个好的分析器会告诉您统计信息，例如函数执行了多少次、函数的平均运行时间、函数的峰值运行时间、函数的总运行时间等。一些分析器甚至会为您绘制图表，以便您可以直观地看到程序的哪些部分是最大的瓶颈，并且您可以深入了解子函数调用。
如果不进行分析，您很可能会错误地判断程序的哪一部分速度较慢。
EQATEC Profiler 就是一个出色的免费 .NET 分析器示例。
There are some things you should do like use generics instead of objects to avoid boxing/unboxing and also improve the code safety, but the best way to optimize your code is to use a profiler to determine which parts of your code are slow. There are many great profilers for .NET code available and they can help determine the bottlenecks in your programs.
Generally you shouldn't concern yourself with small ways to improve code efficiency, but instead when you are done coding, then profile it to find the bottlenecks.
A good profiler will tell you stats like how many times a function was executed, what the average running time was for a function, what the peak running time was for a function, what the total running time was for a function, etc. Some profilers will even draw graphs for you so you can visually see which parts of the program are the biggest bottleneck and you can drill down into the sub function calls.
Without profiling you will most likely be wrong about which part of your program is slow.
An example of a great and free profiler for .NET is the EQATEC Profiler.
关于这个问题最重要的一点是：不要过早优化！
只有一个优化的好时机，那就是当前工作实施无法满足性能限制时。然后，您应该拿出一个分析器并检查代码的哪些部分速度较慢以及如何修复它们。
在编写第一个版本时考虑优化主要是浪费时间和精力。
The single most important thing regarding this question is: Don't optimize prematurely!
There is only one good time to optimize and that is when there are performance constraints that your current working implementation cannot fulfill. Then you should get out a profiler and check which parts of your code are slow and how you can fix them.
Thinking about optimization while coding the first version is mostly wasted time and effort.
“我宁愿选择快速执行的脏代码，而不是那些可能更优雅或更干净但速度较慢的代码。”
如果我正在为游戏编写像素渲染器，也许我会考虑这样做 - 但是，例如，当响应用户单击按钮时，我总是更喜欢较慢、优雅的方法，而不是快速而肮脏的方法（除非慢>几秒钟，那时我可能会重新考虑）。
我必须同意其他帖子 - 配置文件来确定您的慢点在哪里，然后处理这些问题。从一开始就编写最佳代码比它的价值更麻烦，你通常会发现你认为会慢的地方会很好，而真正慢的地方会让你大吃一惊。
"I would rather choose fast-executing dirty code over something which might be more elegant or clean, but slower."
If I were writing a pixel renderer for a game, perhaps I'd consider doing this - however, when responding to a user's click on a button, for example, I'd always favour the slower, elegant approach over quick-and-dirty (unless slow > a few seconds, when I might reconsider).
I have to agree with the other posts - profile to determine where your slow points are and then deal with those. Writing optimal code from the outset is more trouble than its worth, you'll usually find that what you think will be slow will be just fine and the real slow areas will surprise you.
.net 相关性能信息的一个很好的资源是 Rico Mariani 的博客
One good resource for .net related performance info is Rico Mariani's Blog
IMO 对于所有编程平台/语言都是一样的，您必须使用探查器并查看代码的哪一部分很慢，然后对该部分进行优化。
虽然您提供的这些链接很有价值，但不要提前做这样的事情，先测量然后优化。
编辑：
http:// www.codinghorror.com/blog/2009/01/the-sad-tragedy-of-micro-optimization-theater.html
何时使用 StringBuilder？
什么时候使用 StringBuilder 变得微不足道或成为开销？
IMO it's the same for all programming platforms / languages, you have to use profiler and see whitch part of the code are slow, and then do optimization on that parts.
While these links that you provided are valuable insig don't do such things in advance, measure first and then optimize.
edit:
http://www.codinghorror.com/blog/2009/01/the-sad-tragedy-of-micro-optimization-theater.html
When to use StringBuilder?
At what point does using a StringBuilder become insignificant or an overhead?
有很多技巧，但如果这就是您认为需要的，那么您需要重新开始。任何语言的性能秘诀不在于编码技术，而在于找到要优化的内容。
打个比方，如果你是一名警探，你想把强盗关进监狱，那么你的核心任务不是不同类型的监狱。这是关于寻找强盗。
我依靠纯手动的分析方法。 这是查找一系列要优化的点的示例 ，导致加速倍数为 43 倍。
如果您在现有应用程序上执行此操作，您可能会发现性能缓慢的主要原因是过度的数据结构设计，导致过多的通知式一致性维护，其特点是过于茂密的调用树。您需要在调用树中找到成本较高且可以修剪的调用。
完成此操作后，您可能会意识到，使用最少的数据结构和抽象来设计软件的方法一开始就会运行得更快。
There are lots of tricks, but if that's what you're thinking you need, you need to start over. The secret of performance in any language is not in coding techniques, it is in finding what to optimize.
To make an analogy, if you're a police detective, and you want to put robbers in jail, the heart of your business is not about different kinds of jails. It is about finding the robbers.
I rely on a purely manual method of profiling. This is an example of finding a series of points to optimize, resulting in a speedup multiple of 43 times.
If you do this on an existing application, you are likely to discover that the main cause of slow performance is overblown data structure design, resulting in an excess of notification-style consistency maintenance, characterized by an excessively bushy call tree. You need to find the calls in the call tree that cost a lot and that you can prune.
Having done that, you may realize that a way of designing software that uses the bare minimum of data structure and abstractions will run faster to begin with.
如果您对代码进行了分析，发现它缺乏速度，那么有时可以使用一些微观优化。这是一个 简短列表。
明智地进行微观优化——就像《哈利·波特》中的镜子：如果你不小心，你就会把所有的时间都花在那里，却什么也做不了，而且得不到很多回报。
StringBuilder 和异常抛出示例都是很好的示例 - 这些是我曾经犯过的错误，有时会导致函数执行时间增加秒。在进行分析时，我发现我个人花费了很多周期来查找东西。在这种情况下，我使用哈希表（或字典）缓存经常访问的对象。
If you've profiled your code, and found it to be lacking swiftness, then there are some micro-optimizations you can sometimes use. Here's a short list.
Micro-optimize judiciously - it's like the mirror from Harry Potter: if you're not careful you'll spend all your time there and get nothing else done without getting a lot in return.
The StringBuilder and exception throwing examples are good ones - those are mistakes I used to make which sometimes added seconds to a function execution. When profiling, I find I personally use up a lot of cycles simply finding things. In that case, I cache frequently accessed objects using a hashtable (or a dictionary).
良好的程序架构可以为您提供比优化功能更好的优化。
最优化的是避免运行时代码中的所有 if else，将它们全部放在初始化时。
总的来说，优化不是一个好主意，因为最有价值的是可读的程序，而不是快速的程序。
Good program architecture give you a lot better optimization, than optimized function.
The most optimization is to avoiding all if else in runtime code, put them all at initialize time.
Overall, optimization is bad idea, because the most valuable is readable program, not a fast program.
http://www.techgalaxy.net/Docs/Dev/5ways.htm 有一些非常好的观点...今天刚刚遇到。
http://www.techgalaxy.net/Docs/Dev/5ways.htm has some very good points... just came across it today.