Кэш сборки .NET / ngen / jit-образ разогрева и охлаждения

У меня есть программа метода ввода (IME), созданная с помощью C # .NET 2.0 DLL через C ++ / CLI. Поскольку IME всегда присоединяется к другому приложению, C # .NET DLL, похоже, не может избежать изменения адреса изображения.

Хотя я применил ngen для создания собственного образа этой библиотеки C # .NET 2.0 и установил его в Global Assembly Cache, он не улучшился значительно, примерно за 12 секунд. до 9 сек. на медленном ПК уровня PIII.

Поэтому я использую небольшое приложение, которое загружает все компоненты, на которые ссылается C # .NET DLL, во время загрузки, чтобы «разогреть» собственный образ этой DLL. Он отлично работает, чтобы ускорить время загрузки до 0,5 сек.

Однако это сработало лишь на время. Около 30 мин. позже, кажется, снова "остынет".

Есть ли способ контролировать поведение GAC или собственного образа, чтобы он всегда был «горячим»? Это как раз проблема с изменением адреса изображения?


person Community    schedule 14.09.2009    source источник


Ответы (1)


Я думаю, что это скорее всего библиотеки фреймворка и сама среда CLR, находящиеся в кеше Windows.

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

По крайней мере, стоит попробовать - писать совсем не нужно много времени.

person Jon Skeet    schedule 14.09.2009