Ответ 1

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

На основе вашего приложения лучше всего тщательно подумать, можете ли вы разработать свое решение, чтобы избежать динамического. Ниже приведены некоторые допустимые варианты использования для динамических: https://msdn.microsoft.com/en-us/library/dd264736.aspx

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

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

PS: Кроме того, публикация некоторых фрагментов кода помогает.

Ответ 2

Сегодня я столкнулся с такой же проблемой, профайлируя утечки памяти в своем приложении RepoZ. Этот инструмент должен работать в фоновом режиме, периодически проверяя репозитории Git и периодически обновляя заголовки Windows Explorer. Последняя задача должна сделать некоторые вызовы COM для "Shell.Application", чтобы найти окна проводника и определить путь, на который они указывают в настоящее время.

Используя ключевое слово dynamic, подобное этому...

dynamic shell = Activator.CreateInstance(...);
foreach (object window in shell.Windows())
{ 
    var hwnd = window.Hwnd;
    ...
}

... Через несколько часов я дошел до дампа памяти:

ComBridge

Чтобы решить эту проблему, я написал небольшой вспомогательный класс под названием "Комбридж" , заботящийся о выпуске COM-объектов и обеспечивающий довольно легкий доступ к методам и свойства базового COM-объекта. Это очень легко и просто, ничего особенного здесь. Он использует Отражение для объектов COM, поэтому существует некоторая потеря производительности (см. Ниже).

С ним образец кода сверху выглядит следующим образом:

using (var shell = new Combridge(Activator.CreateInstance(...)))
{
    var windows = shell.InvokeMethod<IEnumerable>("Windows");
    foreach (var window in windows)
    {
        var hwnd = window.GetPropertyValue<long>("Hwnd");
        ... 
    }
}

Вы можете увидеть файл ExplorerWindowActor о том, как он используется в RepoZ.

Это не так красиво, как с dynamic, и в этой первой попытке производительность ухудшилась. Быстрая скамья показала следующее:

Производительность

Я протестировал 1000 итераций, на каждой итерации обработано 10 открытых окон Explorer. Для каждого окна на этот COM-объект вызывается 4 метода или свойства. Итак, мы говорим о 40 000 COM-вызовах.

Продолжительность возрастала от ~ 2500 мс (dynamic) до ~ 6000 мс (Combridge). Это от 0.062ms до 0.150ms для каждого вызова.

Таким образом, это займет около 2.4x времени для завершения.

Это важно, я знаю. Но это нормально для моих требований, и утечка памяти ушла.

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

~ ~ Update

Через 10 часов RepoZ все еще работает с очень постоянной памятью.

Таким образом, при открытии 10 окон Explorer, 4 COM-вызовов за окно и весь цикл два раза в секунду, RepoZ создал около 72.000 COM-экземпляров и сделал около 2.880.000 COM-вызовов в целом без увеличения потребления памяти.

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