Управляемая производительность C ++ и C # для CodeModel и других COM-объектов - PullRequest
Новая
       21

Управляемая производительность C ++ и C # для CodeModel и других COM-объектов

1 голос
/ 09 августа 2009

Я создаю расширение для Visual Studio 2008, и поскольку я не хотел писать свой собственный анализатор для C ++ (я не мазохист), я использую VCCodeModel.

Получение простого поля из этих COM-объектов занимает на порядки больше времени, чем любая другая операция, которую я выполняю, и, поскольку я углубляюсь до уровня методов очень больших проектов C ++, у меня эта неэффективность на самых низких уровнях моей рекурсии. 

   vcCodeBaseFunctions = ((Microsoft.VisualStudio.VCCodeModel.VCCodeElements)
                                (vcCM.Functions));
   int i = 0;
   for (i = 1; i <= vcCodeBaseFunctions.Count; i++)
   {
     if (vcCodeBaseFunctions.Item(i).Kind == vsCMElement.vsCMElementFunction)
                parent.AppendChild(MethodWrapper.VCCodeFunctionToXML(
                          (VCCodeFunction)vcCodeBaseFunctions.Item(i)));
   }

Предыдущий код будет перебирать все функции на базовом уровне проекта, преобразовывать их в XML и затем сохранять их. Метод XML будет вызывать несколько полей внутри функции VCCodeFunction, таких как имя, параметры и т. Д.

Управляется ли C ++ быстрее, чем C # для этой цели? У меня неадекватное понимание того, как серверная часть управляемого C ++ отличается от C #, но моя интуиция заставила меня поверить, что затраты на «переключение контекста» между управляемым и неуправляемым кодом в C ++ меньше, но я ошибаюсь? Я получаю значительное замедление от того, что, как я считаю, неоднократно переключается между управляемым и неуправляемым кодом в C ++ с использованием CodeModel, поэтому я прав, полагая, что управляемый C ++ будет быстрее?

Ответы [ 3 ]

1 голос
/ 09 августа 2009

Из-за уровня взаимодействия COM в .NET есть издержки. Если бы вы использовали C ++, вы могли бы переместить свой COM-доступ в собственный код, что ускорило бы этот раздел доступа к коду.

Тем не менее, в какой-то момент у вас все еще будет взаимодействие с native-> управляемого, если вы планируете использовать C ++ / CLI. Где-то в цепочке вы будете распределять данные по всем направлениям, хотя вы можете быть немного быстрее, если вы можете переместить это за пределы этих циклов (если вы сделаете свою рекурсию на 100% нативной, у вас будет гораздо меньше вызовов взаимодействия).

Тем не менее, VCCodeModel не особенно быстр - Хотя я согласен, что вы получаете некоторые накладные расходы с COM-взаимодействием, имейте в виду, что используемый вами профилировщик может преувеличивать это. Это особенно верно, если вы используете профилировщик трассировки, так как во время профилирования вы будете тратить больше времени на эти вызовы, чем на фактический запуск релиза. Профилировщики не идеальны, и это может быть случай, когда вы получаете искаженные результаты из-за вашего профилировщика.

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

0 голосов
/ 09 августа 2009

C ++ вряд ли будет быстрее.

Написание собственного парсера может выполнить быстрее. Конечно, написание собственного парсера может занять гораздо больше времени.

0 голосов
/ 09 августа 2009

Скорость языка надстройки / пакета равна ничего по сравнению со скоростью модели кода. Изменить: хорошо, может быть, я пошел за борт, но серьезно, первое предложение здесь является правильным.

...