Повышение производительности при компиляции кода компонентов .NET 1.1 COM + с помощью компилятора .NET 3.5

Мне нужно создать службу в виде компонента COM + с помощью Enterprise Services.

Сервис работает прямо сейчас. Он получает строку, проверяет орфографию и возвращает строку.

У меня вопрос:

Этот компонент был скомпилирован в .NET 1.1, но моя среда скоро перейдет на .NET 3.5. Итак, если я скомпилирую код в .NET 3.5 (на самом деле это 2.0), будет ли у меня какая-то выгода? Любое изменение производительности только при компиляции в .NET3.5?

Имейте в виду, что я не использую никаких функций .NET3.5 (или даже WCF)!

Спасибо за помощь.


.net compiler-construction com+
person Txugo    schedule 26.02.2010    source источник
comment
Если вы перестроите его для .NET 3.5, он не будет использовать код семилетней давности и будет поддерживаться намного дольше. Это может быть важно на предприятии.   -  person John Saunders    schedule 26.02.2010

Ответы (4)


arrow_upward
2
arrow_downward

В CLR и библиотеках была проведена оптимизация (например, запуск стал быстрее), но трудно сказать, заметите ли вы реальную разницу в скорости. Манипуляции со строками подразумевают, что выделение памяти подразумевает давление на сборщик мусора, поэтому в версии 3.5 это должно быть немного лучше.

Вы получите реальный ответ, только проверив и измерив, извините.

person Timores    schedule 26.02.2010

arrow_upward
1
arrow_downward

По скорости - возможно (но обратите внимание, что .Net 3.5 даже больше, чем 1.1, поскольку он включает новые технологии, такие как LINQ, WCF, CF, WPF и т. Д.)

Развертывание - .net 3.5 будет хорошо, так как последняя версия ОС Windows уже имеет .Net framework 3.0+, доступный в качестве функции в своей системе.

Обслуживание \ Что нужно знать на будущее - .net 3.5. Вам будет лучше перейти на .Net 3.5 сейчас, поэтому, если вам нужно будет внести изменения в свое программное обеспечение, вы уже можете воспользоваться гораздо более новыми доступными технологиями ...

person Jojo Sardez    schedule 26.02.2010
comment
да. но поскольку мне не разрешено использовать WCF и LINQ (а это, в конце концов, было бы полезно в моем решении), мне интересно, в чем польза от этого. Спасибо за ответ. - person Txugo; 26.02.2010
comment
Если вы компилируете версию 3.5, почему вам не разрешено использовать LINQ? Звучит как FUD от высшего руководства. - person mxmissile; 26.02.2010

arrow_upward
1
arrow_downward

Если вы не измените код, чтобы использовать новые функции, такие как общие коллекции, это не сильно изменится. И в большинстве более новых ОС в любом случае не установлены .NET 1 или 1.1, и код запускается с использованием среды выполнения .NET 2 (которая также используется в версии 3.5). Следовательно, вы все равно должны выиграть от улучшенного джиттинга, взаимодействия и т. Д., Которые, возможно, были улучшены в более новых версиях среды выполнения.

Для обычных приложений можно указать в файле конфигурации, какая версия фреймворка будет использоваться, чтобы вы могли принудительно использовать среду выполнения .NET 2 даже для приложения 1 / 1.1. Однако не уверен, работает ли это для вещей, активируемых COM, и как.

person Lucero    schedule 26.02.2010
comment
Точно. поэтому я сказал, что не менял код с версии 1.1 (то есть не использую функции 2.0) и не использую WCF (.NET 3.0) или Linq (3.5). Так что я не понимаю преимуществ. И CLR в 3.5 может запускать сборку 1.1, но если я скомпилирую ее в 3.5 (на самом деле 2.0), я думаю, что это не имеет никакого значения. И документация и комментарии, которые я искал, могут только сказать, что вы все равно должны получить выгоду, но никто не объясняет, как и почему. Спасибо за ваш комментарий. - person Txugo; 26.02.2010

arrow_upward
1
arrow_downward

Загрузка сборок и JIT-компиляция их кода уже были сильно оптимизированы в .NET 1.0. Это очень важно, так как это напрямую влияет на время запуска любого .NET-приложения. В версии 2.0 CLR это существенно не улучшилось.

Однако в .NET 3.5 SP1 было обновление политики безопасности. Строгое имя сборки больше не проверяется, если расположение сборки является доверенным. Точные правила задокументированы здесь . Это может ускорить теплый запуск на 40%. Это оптимистичное число, YMMV.

person Hans Passant    schedule 26.02.2010