Влияет ли пробел и комментарии в коде VBA на производительность?

Пробельные символы и комментарии обычно игнорируются компиляторами и интерпретаторами. Я не могу найти официальное заявление об этом эффекте специально для VBA (аналогично тому, как это делается для кода C в Visual Studio), но из экспериментального тестирования VBA, похоже, ведет себя так же.

Что касается количества кода в VBA, влияющего на производительность процедуры, очевидно, чем больше кода, тем больше времени потребуется процедуре для завершения выполнения.

Из MSDN MS-VBAL Лексические правила

Также помните, что имена переменных и констант не существуют в скомпилированной программе.

3.2.1 Физическая линейная грамматика

module-body-physical-structure = *source-line [non-terminated-line] source-line = *non-line-termination-character line-terminator non-terminated-line = *non-line-termination-character line-terminator = (%x000D %x000A) / %x000D / %x000A / %x2028 / %x2029 non-line-termination-character = <any character other than %x000D / %x000A / %x2028 / %x2029> 

Реализация МОЖЕТ ограничить количество символов, допустимых в физической строке. Значение модуля, который содержит любые физические строки, которые превышают такой предел реализации, не определено этой спецификацией. Если <module-body-Physical Structure> завершается с <non-terminated-line>, то реализация МОЖЕТ обрабатывать модуль так, как если бы за <non-terminated-line> сразу следовал <line-terminator>.

В целях интерпретации текста программы VBA тело модуля (раздел 4.2) рассматривается как набор логических строк, каждая из которых может соответствовать нескольким физическим строкам. Эта структура описывается грамматикой логической линии. Конечными символами этой грамматики являются кодовые точки символов Unicode.

3.2.2 Грамматика логической линии

module-body-logical-structure = *extended-line extended-line = *(line-continuation / non-line-termination-character) line-terminator line-continuation = *WSC underscore *WSC line-terminator WSC = (tab-character / eom-character /space-character / DBCS-whitespace / most-Unicode-class-Zs) tab-character = %x0009 eom-character = %x0019 space-character = %x0020 underscore = %x005F DBCS-whitespace = %x3000 most-Unicode-class-Zs = <all members of Unicode class Zs which are not CP2-characters> 

Реализация МОЖЕТ ограничить количество символов в <расширенной строке>. Для простоты спецификации удобно иметь возможность явно ссылаться на точку, которая непосредственно предшествует началу логической строки, и точку, непосредственно предшествующую конечному ограничителю строки логической строки. Это достигается с помощью <LINE-START> и <LINE-END> в качестве терминальных символов грамматик VBA. <LINE-START> определяется так, чтобы непосредственно предшествовать каждой логической строке, а <LINE-END> определяется как замена <line-terminator> в конце каждой логической строки:

module-body-lines = *logical-line logical-line = LINE-START *extended-line LINE-END 

При использовании в определении правила ABNF <LINE-START> и <LINE-END> используются для указания требуемого начала или конца <логической строки>.

3.3 Лексические токены

Синтаксис программ VBA легче всего описать с помощью лексических токенов, а не отдельных символов Юникода. В частности, появление пробелов или продолжений строк между большинством синтаксических элементов обычно не имеет отношения к синтаксической грамматике. Синтаксическая грамматика значительно упрощается, если ей не нужно описывать такие возможные пробелы. Это достигается с помощью лексических токенов (также называемых просто токенами), которые абстрагируются от пробелов в качестве терминальных символов синтаксической грамматики. Лексическая грамматика определяет интерпретацию <module-body-lines> как набора таких лексических токенов.

Терминальными элементами лексической грамматики являются символы Юникода и элементы <LINE-START> и <LINE-END>. Как правило, любое имя правила лексической грамматики, которое пишется всеми прописными буквами, также является лексическим токеном и терминальным элементом синтаксической грамматики VBA. Цитируемые ABNF правила буквального текста также считаются лексическими токенами синтаксической грамматики. Лексические токены охватывают любые пробельные символы, которые непосредственно предшествуют им. Обратите внимание, что при использовании в лексической грамматике правила литерального текста в кавычках не рассматриваются как токены, и, следовательно, любые предшествующие пробельные символы являются значительными.

3.3.1 Разделитель и специальные токены

WS = 1*(WSC / line-continuation) special-token = "," / "." / "!" / "#" / "&" / "(" / ")" / "*" / "+" / "-" / "/" / ":" / ";" / "<" / "=" / ">" / "?" / "\" / "^" NO-WS = <no whitespace characters allowed here> NO-LINE-CONTINUATION = <a line-continuation is not allowed here> EOL = [WS] LINE-END / single-quote comment-body EOS = *(EOL / ":") ;End Of Statement single-quote = %x0027 ; ' comment-body = *(line-continuation / non-line-termination-character) LINE-END 

<special-token> используется для идентификации отдельных символов, имеющих особое значение в синтаксисе программ VBA. Поскольку они являются лексическими токенами (раздел 3.3), этим символам могут предшествовать символы пробела, которые игнорируются. Любое вхождение одного из цитируемых элементов <special-token> в качестве элемента грамматики в синтаксической грамматике является ссылкой на соответствующий токен (раздел 3.3).

<NO-WS> используется в качестве терминального элемента синтаксической грамматики, чтобы указать, что токену, который следует непосредственно за ним, не должны предшествовать никакие пробельные символы. <NO-LINE-CONTINUATION> используется в качестве терминального элемента синтаксической грамматики, чтобы указать, что токену, который следует непосредственно за ним, не должен предшествовать пробел, который включает в себя любые последовательности <linecontinuation>.

<WS> используется в качестве терминального элемента синтаксической грамматики, чтобы указать, что токену, который следует непосредственно за ним, должен предшествовать один или несколько символов пробела.

<EOL> используется в качестве элемента синтаксической грамматики для именования токена, который действует как маркер «конца оператора» для операторов, которые должны быть единственным или последним оператором в логической строке.

<EOS> используется в качестве терминального элемента синтаксической грамматики для именования токена, который действует как маркер «конца утверждения». Как правило, конец оператора помечается символом <LINE-END> или двоеточием. Любые символы между <single-quote> и <LINE-END> являются текстом комментария, который игнорируется.

You might notice that VBA is parsed into executable tokens at edit time, not at run time.

Multiple inline spaces are compiled as a single n-space token, so they can be re-displayed for editing, but really they are just a single token in the compiled code. So it doesn't matter how many spaces you put between words. 100 is the same as 1.

So this "Correct-by-construction" effectively removes any spaces when you finish editing (not when you run it).

Try it yourself. Put some extra spaces a the end of a line, move to the next line, then move back and the spaces are gone. Also notice that if you try to put in invalid code it complains until you correct it. This is the signature of early parsing and tokenization.

So the answer to your question is that there are no extra spaces when the code runs because the code is pre-compiled, so it CAN'T effect speed.

I think Correct-by-construction is really pretty cool stuff. It's the best of a run time interpreter and fast compiler all in one!

The parser in the Forth computer language did something similar, in how it worked, but of course it didn't have the correct by construction editor. I had always hoped to add one to it.

Для большинства практических ситуаций это действительно не должно иметь никакого влияния.

Хорошо бы рассмотреть использование пробелов и комментариев не для производительности, а для удобства чтения.

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

Теоретически, вы можете поместить в код VBA достаточно лишних пробелов и / или комментариев, чтобы в конечном итоге замедлить работу интерпретатора, но вам, вероятно, понадобится тысячи или 10 тысяч строк лишнего мусора, чтобы заметить разницу ,

Это сделало бы для интересного эксперимента, хотя!