Как избежать сборки мусора в .NET-приложении в реальном времени?

Не удаляйте их сразу. Вызывать сборщик мусора для каждого объекта - плохая идея. Обычно вы, В самом деле, вообще не хотите связываться со сборщиком мусора, и даже критические по времени процессы - это просто условия гонки, ожидающие своего появления, если они настолько чувствительны.

Но если вы знаете, что у вашего приложения будут периоды занятости или малой нагрузки, вы можете попробовать более общий GC.Collect (), когда вы достигнете легкого периода, чтобы стимулировать очистку перед следующим периодом занятости.

Смотрите здесь: http://msdn.microsoft.com/en-us/library/bb384202.aspx

Вы можете сказать сборщику мусора, что в данный момент делаете что-то важное, и он постарается быть к вам вежливым.

Вы можете иметь ограниченное количество экземпляров каждого типа в пуле и повторно использовать уже выполненные с экземплярами. Размер пула будет зависеть от количества сообщений, которые вы будете обрабатывать.

Принуждение к GC.Collect () - вообще плохая идея, оставьте GC делать то, что у него лучше всего получается. Похоже, что лучшим решением было бы использовать пул объектов, который вы можете увеличивать при необходимости - я успешно использовал этот шаблон.

Таким образом, вы избегаете не только сборки мусора, но и регулярных затрат на выделение ресурсов.

Наконец, уверены ли вы, что сборщик мусора вызывает у вас проблемы? Вам, вероятно, следует измерить и доказать это, прежде чем внедрять какие-либо решения для экономии производительности - вы можете заставить себя ненужную работу!

Теоретически сборщик мусора не должен запускаться, если ваш процессор сильно загружен или если это действительно не нужно. Но если вам нужно, вы можете просто сохранить все свои объекты в памяти, возможно, один экземпляр, и никогда не очищать их, если вы не готовы. Вероятно, это единственный способ гарантировать, что сборщик мусора работает.

Если это абсолютно критично по времени, вам следует использовать детерминированную платформу, такую ​​как C / C++. Даже вызов GC.Collect () будет генерировать циклы ЦП.

Ваш вопрос начинается с предложения, что вы хотите сэкономить память, но избавиться от объектов. Это оптимизация, критичная по пространству. Вам нужно решить, чего вы действительно хотите, потому что GC лучше оптимизирует эту ситуацию, чем человек.

Получите хорошее представление и почувствуйте, как ведет себя сборщик мусора, и вы поймете, почему то, о чем вы здесь думаете, не рекомендуется. если вам не нравится, что среда CLR тратит время на перестановку объектов в памяти много.

• http://msdn.microsoft.com/en-us/magazine/bb985010.aspx
• http://msdn.microsoft.com/en-us/magazine/bb985011.aspx

Вместо того, чтобы создавать новый экземпляр объекта каждый раз, когда вы получаете сообщение, почему бы вам не использовать повторно уже использованные объекты? Таким образом, вы не будете бороться со сборщиком мусора, и ваша память кучи не будет фрагментирована. **

Для каждого типа сообщений вы можете создать пул для хранения неиспользуемых экземпляров. Всякий раз, когда вы получаете сетевое сообщение, вы смотрите на тип сообщения, извлекаете ожидающий экземпляр из соответствующего пула и применяете свою бизнес-логику. После этого вы помещаете этот экземпляр объекта сообщения обратно в его пул.

Скорее всего, вы захотите «лениво загружать» свой пул экземплярами, чтобы ваш код легко масштабировался. Следовательно, класс пула должен будет определять, когда был извлечен нулевой экземпляр, и заполнять его перед передачей. Затем, когда вызывающий код помещает его обратно в пул, это настоящий экземпляр.

** «Объединение объектов - это шаблон для использования, который позволяет повторно использовать объекты, а не выделять и освобождать их, что помогает предотвратить фрагментацию кучи, а также дорогостоящее уплотнение сборщика мусора».

http://geekswithblogs.net/robp/archive/2008/08/07/speedy-c-part-2-optimizing-memory-allocations---pooling-and.aspx

Попытки предугадать сборщик мусора - вообще очень плохая идея. В Windows сборщик мусора - поколенческий, и на него можно положиться, поскольку он довольно эффективен. Есть некоторые отмеченные исключения из этого общего правила - наиболее частым из них является возникновение одноразового события, которое, как вы знаете, приведет к смерти множества старых объектов - после того, как объекты будут переведены в Gen2 (самый долгоживущий) они склонны торчать.

В случае, о котором вы упомянули, вы звучите так, как будто вы генерируете несколько недолговечных объектов - это приведет к коллекциям Gen0. В любом случае они случаются относительно часто и являются наиболее эффективными. Вы можете избежать их, имея повторно используемый пул объектов, если хотите, но лучше всего точно убедиться, является ли сборщик мусора проблемой производительности, прежде чем предпринимать такие действия - профилировщик CLR является инструментом для этого.

Следует отметить, что сборщик мусора отличается в разных платформах .NET - на компактной платформе (которая работает на Xbox 360 и на мобильных платформах) это сборщик мусора, не связанный с поколениями, и поэтому вы должны быть намного осторожнее с тем, что мусор, который генерирует ваша программа.

Вы попадаете в себя - используйте пул объектов и повторно используйте эти объекты. Семантика вызовов этого объекта должна быть скрыта за фасадом фабрики. Вам нужно будет увеличить пул заранее определенным способом. Возможно, удваивайте размер каждый раз, когда он достигает предела - алгоритм высокого уровня или фиксированный процент. Я настоятельно рекомендую вам не вызывать GC.Collect ().

Когда нагрузка на пул станет достаточно низкой, вы можете сжать пул, что в конечном итоге вызовет сборку мусора - пусть CLR позаботится об этом.

Судя по звучанию, похоже, что вы говорите о детерминированной финализации (деструкторы в C++), которой нет в C#. Самое близкое, что вы найдете в C#, - это шаблон Disposable. В основном вы реализуете интерфейс IDisposable.

Базовый паттерн таков:

public class MyClass: IDisposable
{
    private bool _disposed;

    public void Dispose()
    {
        Dispose( true );
        GC.SuppressFinalize( this );
    }

    protected virtual void Dispose( bool disposing )
    {
        if ( _disposed )    
            return;

        if ( disposing )
        {
            // Dispose managed resources here
        }

        _disposed = true;
    }
}

Насколько интенсивно приложение? Я написал приложение, которое захватывает 3 звуковые карты (Managed DirectX, 44,1 кГц, стерео, 16 бит) блоками по 8 КБ и отправляет 2 из 3 потоков на другой компьютер через TCP / IP. Пользовательский интерфейс отображает измеритель уровня звука и (плавную) прокрутку названия / исполнителя для каждого из 3 каналов. Это работает на ПК с XP, 1,8 ГГц, 512 МБ и т. д. Приложение использует около 5% ЦП.

Я избегал ручного вызова методов GC. Но мне все же пришлось настроить несколько бесполезных вещей. Я использовал профайлер Ant от RedGate, чтобы отточить расточительные части. Отличный инструмент!

Я хотел использовать пул предварительно выделенных байтовых массивов, но управляемая сборка DX выделяет байтовые буферы внутри, а затем возвращает их в приложение. Оказалось, что не надо было.

«Цель состоит в том, чтобы избежать сборки мусора для использования любого процессора во время критичного по времени процесса»

Вопрос: Если под критическим временем вы имеете в виду, что слушаете какое-то эзотерическое оборудование, и вы не можете позволить себе пропустить прерывание?

А: Если это так, то C# не подходит для использования, для этого вам нужен Ассемблер, C или C++.

Вопрос: Если под критическим временем, вы имеете в виду, когда в канале много сообщений, и вы не хотите, чтобы сборщик мусора замедлял работу?

А: Если так, то напрасно беспокоитесь. Судя по звукам вещей, ваши объекты очень недолговечны, это означает, что сборщик мусора будет перерабатывать их очень эффективно, без видимого отставания в производительности.

Тем не менее, единственный способ узнать наверняка - это протестировать его, настроить на выполнение в ночное время обработки постоянного потока тестовых сообщений, я буду ошеломлен, если ваша статистика производительности сможет определить, когда срабатывает сборщик мусора (и даже если вы можете заметьте это, я буду еще больше удивлен, если это действительно имеет значение).