Какую производительность наверху контейнеры МОК включают?
Даже если бы существует такой инструмент, я настоятельно рекомендовал бы Вам, чтобы сделать преобразование вручную. Автоматические преобразователи будут часто искренне воспроизводить код, но игнорировать идиомы - потому что они были бы должны действительно, действительно трудно для разбираний.
, Кроме того, различия между дженериками в.NET и Java могли привести к некоторым совсем другим решениям в этих двух кодовых базах.
Действительно, Вы будете более обеспеченным выполнением его вручную.
3 ответа
Есть ссылки о производительности
http://realfiction.net/?q=node/143
Есть результаты
- Обычное строительство: 0,0001 / 0,0002
- Строительство активатора: 0,0069 / 0,0071
- Строительство контейнера (Castle Windsor): 0,1014 / 0,1068
- Строительство контейнера (Spring.NET): 0,069 / 0,0722
Но как вы можете видеть Windsor - не самый быстрый IoC (Autofac намного быстрее)
Правильный ответ: производительность не имеет значения :).
Поскольку правильное использование IoC, когда весь процесс регистрации находится на этапе инициализации.
Другими словами, использование IoC должно уменьшать количество ваших «if else» в реальном времени.
У вас будет более медленное время инициализации, так как все загружается при запуске контейнера. Если время инициализации для вас не имеет значения, в этом колесе удачи выигрывают все.
Лучший способ понять, насколько сложен контейнер IoC, - это проанализировать его.
В одном конкретном случае однажды я потратил целый день на отладку простого кода «Hello World», используя plexus , на котором основан Maven (, и вот полезная ссылка для просмотра его исходного кода ). Это вроде как возникло (глядя на defaultPlexusContainer) как:
- Конфигурация пути к классам (через миры классов)
- Создание переменной контекста времени выполнения (в основном карта) для хранения свойств и переменных
- Анализ конфигурации (обнаружение метаданных модулей в пути к классам и т. д.)
- Инициализация:
- Создание / создание служб
- Запуск дополнительных ComponentDiscoverers
- Запуск дополнительных ComponentDiscovererListeners
Это оставляет важный аспект, глубоко описанный выше: поиск компонента. В сплетении концепция фаз охватывает этапы построения объекта, и эти фазы обычно связаны с концепцией личности. Однако для настройки по умолчанию это выполняется путем выполнения следующих этапов:
- Создание экземпляра объекта (т. Е. Новый объект ())
- Включение журнала (т. Е. Установка регистратора для объекта)
- Состав: то есть поиск и настройка зависимости
- Стратегия установки - интересный момент, но я пока оставлю подробности
- Передача контекста в созданный объект
- Дополнительная процедура запуска объекта
Большинство этих шагов являются необязательными, и обычно включает идентификацию данного интерфейса и его вызов на целевом объекте - это значение по умолчанию для индивидуальности сплетения, обратите внимание, что.
Кроме того, каждый объект может быть привязан к диспетчеру жизненного цикла, что в основном определяет разницу между новым объектом и синглтон.
В моем конкретном отчете: Самая сложная часть на самом деле - это анализ конфигурации и загрузка контейнера. После этого вы, вероятно, больше не заметите разницы в производительности.