2016-06-20 3 views
2

Мне любопытно сравнение производительности двух, если бы вы хотели написать функционально идентичные программы. Я работаю над проектом, где я начинаю думать, что addin может быть более подходящим, учитывая объем функций сравнения, которые мне нужно делать в VBA.VSTO Надстройка против производительности VBA

ответ

11

Зависит от того, что делают эти программы и как они это делают.

VSTO /.net быстрее, чем VBA, и позволяет писать код, который работает на нескольких потоках. Но Excel - это COM, и в конечном итоге все должно попасть в конвейер STA (Single-Threaded Apartment), а управляемый (.net) код взаимодействует с COM через COM Interop, то есть он разговаривает с Excel через Primary Interop Assemblies, который медленнее, чем «родной» VBA.

Другими словами:

  • Ваша программа делает много обработки и очень немногие из таблицы операций чтения/записи, перейдите VSTO.
  • Ваша программа делает много взаимодействий в электронной таблице, переходите в VBA. Взаимодействие электронных таблиц - это в значительной степени самая медленная вещь, которую может сделать VBA, но делать их с VSTO будет еще более болезненным, потому что все должно быть обработано с управляемого кода до COM.

Best может быть гибридное решение: выставить определенные пользователем функции в VBA, и сделать код вызова VBA в ссылочного COM-видимой .net DLL, которая делает фактическое вычисление даже работая с сборок взаимодействия Excel.

Хорошо написанный код VBA может превосходить эквивалентный код VSTO.

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

Вы также можете написать надстройку Excel в VBA. Чем меньше задействованных технологий, тем меньше им приходится разговаривать друг с другом; в конце концов, это баланс между тем, сколько значение вы даете ряд вещей, которые могут применяться по-разному в зависимости от ваших требований, окружающей среды и опыт:

  • Performance - какое решение лучше всего работает?
  • Поддержание работоспособности - какое решение проще всего поддерживать?
  • Развертывание - какое решение проще всего обновить и развернуть?
  • Источник управления - Визуальные крючки Студийные к Team Разочарование Foundation Server и Git; VBE может делать Git с Rubberduck (мой маленький проект моего любимого), но последняя версия по-прежнему остается бета-версией и немного нестабильной (это open-source, поэтому, если вы знаете C#, вы можете внести свой вклад и помочь стабилизировать ее).
  • Unit Testing - Visual Studio позволяет легко писать и выполнять модульные тесты; VBE может сделать то же самое с Rubberduck, но без надстройки VBE вам придется прибегать к ad-hoc-тестам или разрешать программный доступ к API VBIDE и использовать платформу модульного тестирования на основе VBA.
+0

Отличный отклик. Более чем достаточно информации. Спасибо. – Flibertyjibbet

+0

Было бы полезно узнать больше об модульном тестировании. Можно ли запускать тесты из CI, например TeamCity? –

+0

@ AndreyKlochkov, если вы полностью отделили свой код VSTO от объектной модели Office, да. В противном случае вам нужно будет запустить Office на сервере CI, и это не то, что я бы рекомендовал. Например, [Rubberduck] (http://rubberduckvba.com) построен на сервере CI, но мы обертываем весь API VBIDE, чтобы иметь возможность сделать это, и использовать [Moq] (https: // github .com/Moq/moq4/wiki/Quickstart) для реализации реализаций для этих интерфейсов. Выполнение кода VBA на сервере CI невозможно. –

Смежные вопросы