（同样，级别相当低）您是否在 IL 中寻找过任何愚蠢的内容？我最近发现很多周期（在某些特定代码中）都花在了堆栈上的内容上，以传递适当的参数。通过更改代码（并且，诚然，做了一些自定义 IL），我消除了所有不必要的（改组）stloc/ldloc，并删除了几乎所有本地变量（减少了进程中的堆栈大小）
但老实说，您需要在这里进行分析。专注于真正重要的事情，或者你知道需要解决的问题。
It is usually pretty rare that you need to go down to this level, but I'm doing something pretty similar at the moment; some thoughts:
do you have any buffers in regular use? Have you considered pooling them? i.e. so that instead of creating a new one you ask a pool to get (or create) one?
have you removed any reflection? (replacing with typed delegates, DynamicMethod, etc) - or taking it hardcore, Reflection.Emit?
have you considered unsafe? (used sparingly, in places where you have a measured need to do so)
(again, pretty low level) have you looked for anything silly in the IL? I recently found a lot of cycles (in some specific code) were being spent shuffling things around on the stack to pass in parameters appropriate. By changing the code (and, admittedly doing some custom IL) I've eliminated all the unnecessary (shuffling) stloc/ldloc, and removes almost all of the locals (reducing the stack size in the process)
But honestly, you need to profile here. Focus on things that actually matter, or where you know you have a problem to fix.
特定于 Windows 窗体 .NET，关闭 DataGridView.AutoSizeColumnsMode 和 AutoSizeRowMode。
If there is a lot of string manipulation in your application, use StringBuilder instead of string. The performance of the application will increase considerably.
Also replace string concatenations (+ operator) with StringBuilder.
Specific for Windows Forms .NET, turn off DataGridView.AutoSizeColumnsMode and AutoSizeRowMode.
You are mentioning arrays being faster than List's. The CLR will actually do basic bounds checking for you when you are accessing an array. So, you will be able to gain a bit more performance by using the unsafe keyword, and then accessing the array using pointer arithmetic. Only do this if you actually need it - and you can measure a performance improvement for your specific scenario.
When you ask about low-level optimizations (which nearly everyone does) you are basically guessing that those things will matter. Maybe at some level they will, but nearly everyone underestimates what can be saved by high-level optimization, which cannot be done by guessing.
It's like the proverbial iceberg, where what you can see is a tiny fraction of what's there.
Here's an example. I hesitate to say "use a profiler" because I don't. Instead, I do this which, in my experience, works much better.
Let the garbage collector (GC) do its work and do not interfere with calling GC.Collect directly. This will hinder the built-in GC algorithm to run effectively in turn run slower and your call to GC.Collect can add unnecessary overhead too.
For GDI+ specific, call Invalidate to invalidate the client area or specific rectangle of a control or form instead of calling Refresh which call invalidate and update to repaint the control.
Wrong language. For total optimization you need something lower level. Mostly not needed, though.
Note BTW., that your indication of arrays and lists is wrong... List is, depending on which you choose, a linked list, so has a different performance characteristics than an array. But that is not a CLR / runtime thing.
Besides the StringBuilder - my main advice is: use a profiler. Most people try to be smart with speed, but never profile, so spend a lot of time on useless optimizations later on - thy get faster, but bad bang for the buck. Find out first where the application actually spends the time.
发布评论
评论（7）
通常很少需要降低到这个级别，但我现在正在做一些非常类似的事情；一些想法：
DynamicMethod等替换） - 或者采用硬核、Reflection.Emit？不安全吗？ （谨慎使用，在您有一定需要的地方）stloc/ldloc，并删除了几乎所有本地变量（减少了进程中的堆栈大小）但老实说，您需要在这里进行分析。专注于真正重要的事情，或者你知道需要解决的问题。
It is usually pretty rare that you need to go down to this level, but I'm doing something pretty similar at the moment; some thoughts:
DynamicMethod, etc) - or taking it hardcore,Reflection.Emit?unsafe? (used sparingly, in places where you have a measured need to do so)stloc/ldloc, and removes almost all of the locals (reducing the stack size in the process)But honestly, you need to profile here. Focus on things that actually matter, or where you know you have a problem to fix.
如果应用程序中有大量字符串操作，请使用 StringBuilder 而不是字符串。应用程序的性能将显着提高。
还要用 StringBuilder 替换字符串连接（+ 运算符）。
特定于 Windows 窗体 .NET，关闭
DataGridView.AutoSizeColumnsMode和AutoSizeRowMode。If there is a lot of string manipulation in your application, use StringBuilder instead of string. The performance of the application will increase considerably.
Also replace string concatenations (+ operator) with StringBuilder.
Specific for Windows Forms .NET, turn off
DataGridView.AutoSizeColumnsModeandAutoSizeRowMode.您提到数组比列表更快。当您访问数组时，CLR 实际上会为您执行基本的边界检查。因此，通过使用 unsafe 关键字，然后使用指针算术访问数组，您将能够获得更多的性能。仅当您确实需要时才执行此操作 - 并且您可以衡量特定场景的性能改进。
You are mentioning arrays being faster than List's. The CLR will actually do basic bounds checking for you when you are accessing an array. So, you will be able to gain a bit more performance by using the unsafe keyword, and then accessing the array using pointer arithmetic. Only do this if you actually need it - and you can measure a performance improvement for your specific scenario.
当您询问低级优化（几乎每个人都会这样做）时，您基本上是在猜测这些事情很重要。也许在某种程度上他们会这样做，但几乎每个人都低估了高级优化可以节省的东西，而高级优化是无法通过猜测来完成的。
就像众所周知的冰山一样，你所看到的只是冰山的一小部分。
这是一个示例。我犹豫是否要说“使用分析器” “因为我不这样做。
相反，我这样做，根据我的经验，这是有效的好多了。
When you ask about low-level optimizations (which nearly everyone does) you are basically guessing that those things will matter. Maybe at some level they will, but nearly everyone underestimates what can be saved by high-level optimization, which cannot be done by guessing.
It's like the proverbial iceberg, where what you can see is a tiny fraction of what's there.
Here's an example. I hesitate to say "use a profiler" because I don't.
Instead, I do this which, in my experience, works much better.
让垃圾收集器 (GC) 完成其工作，并且不干扰直接调用 GC.Collect。这将阻碍内置 GC 算法有效运行，进而运行速度变慢，并且您对 GC.Collect 的调用也会增加不必要的开销。
对于特定于 GDI+ 的情况，调用
Invalidate使客户区或控件或窗体的特定矩形无效，而不是调用Refresh，后者会调用invalidate和update重新绘制控件。Let the garbage collector (GC) do its work and do not interfere with calling
GC.Collectdirectly. This will hinder the built-in GC algorithm to run effectively in turn run slower and your call toGC.Collectcan add unnecessary overhead too.For GDI+ specific, call
Invalidateto invalidate the client area or specific rectangle of a control or form instead of callingRefreshwhich callinvalidateandupdateto repaint the control.构建您的系统，运行它，然后附加分析器来查看速度慢的地方。然后使用 StackOverflow、Google 和常识来加快这些领域的速度。
最重要的是不要浪费时间去加速那些实际上不重要的事情，所以分析非常重要。
Build your system, run it, then attach a profiler to see what's slow. Then use Stack Overflow, Google, and common sense to speed those areas up.
The most important thing is to not waste time speeding up things that actually don't matter, so profiling is very important.
您可能指的是高速，而不是低速。
语言错误。为了全面优化，您需要较低级别的东西。不过，大多数情况下不需要。
请注意，顺便说一句，您对数组和列表的指示是错误的...根据您选择的列表，列表是链接列表，因此具有与数组不同的性能特征。但这不是 CLR/运行时的事情。
除了 StringBuilder - 我的主要建议是：使用分析器。大多数人都试图在速度上变得聪明，但从不进行分析，所以以后要花很多时间在无用的优化上——你会变得更快，但物有所值。首先找出应用程序实际将时间花在哪里。
You possibly mean HIGH speeds, not low speeds.
Wrong language. For total optimization you need something lower level. Mostly not needed, though.
Note BTW., that your indication of arrays and lists is wrong... List is, depending on which you choose, a linked list, so has a different performance characteristics than an array. But that is not a CLR / runtime thing.
Besides the StringBuilder - my main advice is: use a profiler. Most people try to be smart with speed, but never profile, so spend a lot of time on useless optimizations later on - thy get faster, but bad bang for the buck. Find out first where the application actually spends the time.