如何最小化垃圾收集的长度 [英] How to minimize the length of the garbage collections

问题描述

在C＃.NET中，我需要一个能够顺利运行的应用程序。我有很多串行计算需要在短时间内连续执行，所以我不介意GC做它的工作和我甚至可以采取更频繁的收集但我需要什么最小化是每个 GC集合的长度。



我希望（如果可能的话）最大1毫秒的线程暂停活动每次由于GC。



在.NET中实现这一目标的最佳方法是什么？我知道.NET不是技术这样的要求，但如果它能够满足我的要求，那么优化后的开发时间的节省和未来规格的灵活性是尝试它的良好动机）？

解决方案

你不是处理实时系统，你不能直接和确定地影响线程调度。您只能更改优先级和...您的设计。您无法真正影响GC行为的安排。所有你提到的都是完全失控的。



同时，某种平滑是完全可能的。例如，我可以解释为什么某些物理的动画可以是平滑的。这是通过在方程中使用实时测量来完成的，而不对计算周期的时间做任何假设。



结论将是：你要么可以通过某些应用程序设计实现平滑，并且在更糟糕的情况下，通过调整流程和线程优先级（这可以仅为您提供概率上的好处），或者您根本无法改进任何内容。在所有情况下，您都无法根据影响GC的调度或线程调度程序来获得任何改进。 GC调度由其自己的算法完成，不会受到影响。例如，如果以较小的块存储内存，则不会在相同的较小块中回收它。此外，你可能夸大了GC的性能成本。



请在我的评论中考虑你的问题，关于过早的判断和知识产权。

-SA

从这里开始：

http://www.toptal.com/c-sharp/top-10-mistakes-that- c-sharp-programmers-make [ ^ ]



https://channel9.msdn.com/posts/YOW-2012-Martin-Thompson-Mechanical-Sympathy-and-High-Performance-Coding [ ^ ]



和我的英雄 Martin Thompson ： http://mechanical-sympathy.blogspot.com/ [ ^ ]

< blockquote>如果垃圾收集对您的应用程序来说是一个问题，那么在这种情况下您可能不应该使用.NET。众所周知，托管代码可能会有这些延迟。因此，对于像视频编辑或低延迟多轨音频这样的应用，通常会建议本机编程。



.NET可以轻松编写多种应用程序但是当需要非常低的延迟时，它不是合适的技术。



根据应用程序的不同，如果你不使用太多，你可以避免这个问题管理内存或通过在关键处理之前分配内存来优化其使用方式。



如前所述，如果需要确保系统，则无法做多少事情不会暂停超过1毫秒。据我所知，暂停可能远高于此。



也许一个解决方案就是关键代码会在自己的umnmaged线程中运行。不确定是否可能在同一个应用程序中，但应该可以使用2个与管道或共享内存或类似内容通信的应用程序。



如果不起作用，然后考虑将您的应用程序重写为本机应用程序。

In C#.NET, I need an application that will run smoothly. I have many serial chunks of computations I need to consecutively perform in short periods of time each, so I don't mind the GC doing it's job and I even can take more frequent collections but what I need to minimize is the length of each GC collection.

I would like (if possible) to have 1 milli max pause of thread activity due to the GC each time.

what is the best way to acheive this in .NET (I know that .NET it not the technology for such demands but if it will meet my demands when optimized the save of development hours and flexibility for future specs is good incentive to try it out)?

解决方案

You are not dealing with a real-time system, and you cannot directly and deterministically affect thread scheduling. You can only change priorities and… your design. You cannot really affect the scheduling of GC behavior. All you mention is completely out of control.

At the same time, some kind of "smoothness" is quite possible. For example, I can explain why animation of some "physics" can be smooth. This is done by getting real time measurement to be used in equations, without making any assumptions on the timing of your computational cycle.

The conclusion would be: you either can achieve "smoothness" by certain application design, and, in worse cases, by adjusting process and thread priorities (which can give you only probabilistic benefits), or you cannot improve anything at all. In all cases, you cannot get any improvements based on affecting scheduling of GC or, say, thread scheduler. GC scheduling is done by its own algorithm and cannot be affected. For example, if you take memory in smaller chunks, it won't be reclaimed in the same smaller chunks. Besides, you probably exaggerate the performance cost of GC.

And please think at my comment to your question, on the premature judgement and intellectual property.

—SA

Start here :
http://www.toptal.com/c-sharp/top-10-mistakes-that-c-sharp-programmers-make[^]

https://channel9.msdn.com/posts/YOW-2012-Martin-Thompson-Mechanical-Sympathy-and-High-Performance-Coding[^]

and my hero Martin Thompson : http://mechanical-sympathy.blogspot.com/[^]

If garbage collection is a problem for your application, then maybe you should not use .NET in that case. This is well known that managed code could have those delays. So for application like video editing or low-latency multi-track audio, native programming would generally be recommand.

.NET make it easy to write many kind of applications but when very low latency is required, it is not the appropriate technology.

Depending on the application you might be able to mostly avoid the problem if you don't use much managed memory or optimize how it is used by maybe allocating memory before critical processing.

As already mentionned, there are not much you can do if you need to ensure the system won't pause for more than 1 ms. As far as I know, pause can be much higher than that.

Maybe one solution would be that critical code would run in its own umnmaged thread. Not sure if it possible in same application but it should be possible with 2 applications that communicate with pipe or shared memory or something like that.

If that does not work, then consider rewriting your application as a native one.

这篇关于如何最小化垃圾收集的长度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！