Интересно.
A обзор 2007 содержит это:
{smartassembly} использует несколько разных
методы, чтобы сбить память
использование.
Мы попросили разработчиков
{smartassembly} для некоторых из
конкретику, и они сказали нам, что
по умолчанию CLR резервирует тонну
память для .NET сборок - будь
или нет они просят это. Так
{smartassembly} интеллектуально обнаруживает
когда процессор простаивает (или около того)
и увеличивает или уменьшает количество
зарезервированной памяти для вашей сборки
в соответствии с его требованиями -
"автоматизированный" GC в некотором смысле, за исключением того, что
память может или не может быть когда-либо
используется.
В том же духе, {smartassembly}
(с преимуществом буквально имея
доступ к вашему исходному коду благодаря
способ .NET разработан) отмечает любой
и все классы, которые не имеют каких-либо
обнаруживаемые "дочерние" классы наследования
из них как "запечатаны" тем самым уменьшая
количество памяти и процессора, используемого
CLR во время выполнения, чтобы определить
какие функции должны быть сделаны
доступны для других классов и
библиотеки.
В том же обзоре есть пара "до / после" скриншотов, показывающих, что приложение идет от 8M до 420K. Это наводит меня на мысль, что на самом деле это просто сокращает рабочий набор приложения, а не реальные требования к памяти. Та же самая «оптимизация» может возникнуть, если вы свернете приложение. Это внезапно не занимает меньше памяти. Я не верю, что настольный .NET Framework может действительно работать только с 420K.
Интересна функция автоматического запечатывания - я не вижу, чтобы это помогло, кроме как для поиска виртуальных методов. Я сомневаюсь, что воздействие действительно значимо, но, конечно, я не оценил его.
Итак, ничего убедительного, но я сомневаюсь, что он делает все, что я особенно хочу.