Скорость генерации DynamicProxy - PullRequest
Новая
       27

Скорость генерации DynamicProxy

5 голосов
/ 03 сентября 2011

Я пытаюсь устранить некоторые проблемы со временем запуска. После некоторого профилирования я обнаружил, что основным виновником является ClassProxyGenerator.GenerateCode. Это занимает 400-600 мс на тип в первый раз. Таким образом, если точка входа в приложение имеет 8 зависимостей (в цепочке), для которых нужны сгенерированные прокси, время запуска приложения увеличивается на 4,8 секунды. Это может показаться не слишком много, но для пользователя это выглядит как возраст.

Какой совет по улучшению?

Обновление:

Я могу воспроизвести время с помощью следующего консольного приложения: 

        var container = new WindsorContainer();
        container.Register(Component.For<Interceptor>()); // dummy IInterceptor...does nothing
        container.Register(Component.For<IMyRepository, MyAbstractRepository>().Interceptors<Interceptor>());
        var t = DateTime.Now;
        var instance = container.Resolve<IMyRepository>();
        Debug.WriteLine("Resolved in " + (DateTime.Now - t).TotalMilliseconds);

Выходы где-то между 550 мс и 750 мс.

IMyRepository - это интерфейс репозитория для 30 типов сущностей (сгенерированный шаблоном T4). Он имеет 31 IQueryables, 31 перегрузок Save и 31 перегрузок Delete. MyAbstractRepository является частичным абстрактным классом. Он объявляет те же 3 х 31 методы.

Если я удаляю все методы сохранения и удаления и оставляю только 31 IQueryables И не регистрирую абстрактный репозиторий 

  container.Register(Component.For<IMyRepository>().Interceptors<Interceptor>());

Я все еще бегаю около 250 мсек для начального поколения.

Это очень (очень-очень) быстрая машина ... поэтому все в реальном мире, вероятно, будет работать медленнее, чем числа, перечисленные выше.

1 Ответ

1 голос
/ 03 сентября 2011

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

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

Я не уверен, почему динамические прокси Касла так долго инициализируются.Я не использую их, я обычно генерирую код напрямую (либо в виде LCG для простых методов, либо через полный Reflection.Emit для полных реализаций).У меня никогда не было таких длительных задержек, даже при создании сотен методов LCG.Возможно, использование другого подхода / библиотеки (LinFu и т. Д.) Также может решить эту проблему.

...