VBA vs VB.net производительность с базой Excel

Question

У меня есть листы с 80*15*5 = 6000 точками данных, созданными из таблиц сводных таблиц Excel. Я должен сделать выбор между программированием в Visual Basic for Applications и Visual Basic.net или работать с формулами Excel. Все данные должны анализироваться по-разному, разные вещи должны быть рассчитаны, и пользователь должен иметь возможность генерировать вывод удобным для пользователя способом без какого-либо знания данных.

Небольшая примерная программа с петлей в цикле в цикле стоит 100 секунд в VBA и 34 на Visual Basic.net. Если я собираюсь работать с формулами Excel, мне также нужно запрограммировать несколько функций, потому что они еще не существуют в Excel. Сейчас я делаю это для другой программы, и это довольно медленно на компьютерах моей компании.

Время работы заставляет меня выбирать для VB.net, но будет ли это еще быстрее, если внешняя программа, созданная VB.net, должна установить соединение с базой данных Excel? Относительно простой способ использования этих данных в VBA заставляет меня хотеть выбирать для VBA.

Помимо этого, я полагаю, что работа с формулами Excel не самая удобная, потому что 80 и 15 в формуле выше могут со временем стать более крупными.

Есть ли что сказать вообще о том, почему я должен выбрать, какое решение?

Answer 1

Руки вниз, вы должны придерживаться VBA, потому что, когда вы используете .NET для подключения к «неуправляемым» (не .NET) приложениям, вам придется управлять памятью гораздо активнее, чем если вы просто придерживаетесь VBA. .NET в Excel использует «Скрытые вызовы во время выполнения» за кулисами, чтобы две архитектуры могли обмениваться данными, но они используют разные механизмы управления памятью.

С Excel, в частности, многие объекты возвращаются из вызовов методов, но вам не нужно ничего с ними делать. Если вы не знаете об этом (и это довольно легко сделать), эти объекты останутся в памяти и сохранят Excel даже после того, как приложение .NET будет прекращено. Очистка после того, как все эти объекты связаны со многими звонками до System.Marshal.ReleaseComObject().

Что касается проблемы с производительностью, которую вы упомянули (цикл в цикле в цикле), это просто (простите) плохую практику программирования на любом языке. Редко приходится делать что-то подобное, и если вы это делаете, вам, вероятно, следует подумать о своем подходе.

Кроме того, ОЧЕНЬ ВАЖНО, чтобы понять, что VB.NET и VBA - совершенно разные языки, даже если они кажутся очень похожими на поверхности. Лучшие практики и общие методы VBA не должны переноситься на VB.NET. Если вы не знакомы с .NET, сначала захотите сделать серьезные исследования.

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