Eu sou novo na programação VBA. Acho que já vi em algum lugar, mas esqueci completamente onde o vi. Talvez eu tenha ouvido de alguém.
Minha pergunta: a quantidade de comentários e espaço em branco no VBA afeta o desempenho do código?
Eu acho que deve ser o mesmo no Excel e no Access, mas eu não quero assumir, então vou especificar que estou usando o Access 2003.
Caracteres e comentários de espaço em branco geralmente são ignorados por compiladores e intérpretes. Não consigo encontrar uma declaração oficial para esse efeito especificamente para o VBA (semelhante a this para C código no Visual Studio), mas a partir do teste experimental, o VBA parece se comportar da mesma maneira.
Em relação à quantidade de código no VBA que afeta o desempenho de um procedimento, obviamente, quanto mais código, mais tempo o procedimento levará para concluir a execução.
De Regras Lexical do MSDN MS-VBAL
Lembre-se também que nomes de variáveis e constantes não existem em um programa compilado.
3.2.1 Gramática de linhas físicas
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>An implementation MAY limit the number of characters allowed in a physical line. The meaning of a module that contains any physical lines that exceed such an implementation limit is undefined by this specification. If a <module-body-physical-structure> concludes with a <non-terminated-line> then an implementation MAY treat the module as if the <non-terminated-line> was immediately followed by a <line-terminator>.
For the purposes of interpretation as VBA program text, a module body (section 4.2) is viewed as a set of logical lines each of which may correspond to multiple physical lines. This structure is described by the Logical Line Grammar. The terminal symbols of this grammar are Unicode character codepoints.
3.2.2 Gramática de linhas lógicas
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>An implementation MAY limit the number of characters in an <extended-line>. For ease of specification it is convenient to be able to explicitly refer to the point that immediately precedes the beginning of a logical line and the point immediately preceding the final line-terminator of a logical line. This is accomplished using <LINE-START> and <LINE-END> as terminal symbols of the VBA grammars. A <LINE-START> is defined to immediately precede each logical line and a <LINE-END> is defined as replacing the <line-terminator> at the end of each logical line:
module-body-lines = *logical-line logical-line = LINE-START *extended-line LINE-ENDWhen used in an ABNF rule definition <LINE-START> and <LINE-END> are used to indicated the required start or end of a <logical-line>.
The syntax of VBA programs is most easily described in terms of lexical tokens rather than individual Unicode characters. In particular, the occurrence of whitespace or line-continuations between most syntactic elements is usually irrelevant to the syntactic grammar. The syntactic grammar is significantly simplified if it does not have to describe such possible whitespace occurrences. This is accomplished by using lexical tokens (also referred to simply as tokens) that abstract away whitespace as the terminal symbols of the syntactic grammar. The lexical grammar defines the interpretation of a <module-body-lines> as a set of such lexical tokens.
The terminal elements of the lexical grammar are Unicode characters and the <LINE-START> and <LINE-END> elements. Generally any rule name of the lexical grammar that is written in all upper case characters is also a lexical token and terminal element of the VBA syntactic grammar. ABNF quoted literal text rules are also considered to be lexical tokens of the syntactic grammar. Lexical tokens encompass any white space characters that immediate precede them. Note that when used within the lexical grammar, quoted literal text rules are not treated as tokens and hence any preceding whitespace characters are significant.
3.3.1 Separador e tokens especiais
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> is used to identify single characters that have special meaning in the syntax of VBA programs. Because they are lexical tokens (section 3.3), these characters may be preceded by white space characters that are ignored. Any occurrence of one of the quoted <special-token> elements as a grammar element within the syntactic grammar is a reference to the corresponding token (section 3.3).
<NO-WS> is used as terminal element of the syntactic grammar to indicate that the token that immediately follows it must not be preceded by any white space characters. <NO-LINE-CONTINUATION> is used as terminal element of the syntactic grammar to indicate that the token that immediately follows it must not be preceded by white space that includes any <linecontinuation> sequences.
<WS> is used as a terminal element of the syntactic grammar to indicate that the token that immediately follows it must have been preceded by one or more white space characters.
<EOL> is used as element of the syntactic grammar to name the token that acts as an "end of statement" marker for statements that must be the only or last statement on a logical line.
<EOS> is used as a terminal element of the syntactic grammar to name the token that acts as an "end of statement" marker. In general, the end of statement is marked by either a <LINE-END> or a colon character. Any characters between a <single-quote> and a <LINE-END> are comment text that is ignored.
Você pode notar que o VBA é analisado em tokens executáveis no momento da edição, não no tempo de execução.
Vários espaços inline são compilados como um único token de n-espaço, para que possam ser exibidos novamente para edição, mas na verdade são apenas um único token no código compilado. Portanto, não importa quantos espaços você coloca entre as palavras. 100 é o mesmo que 1.
Portanto, este "Corrigir-por-construção" remove efetivamente todos os espaços quando você terminar de editar (não quando você executá-lo).
Tente você mesmo. Coloque alguns espaços extras no final de uma linha, vá para a próxima linha, depois volte e os espaços desaparecerão. Observe também que, se você tentar colocar um código inválido, ele irá reclamar até que você o corrija. Esta é a assinatura da análise e tokenização antecipada.
Portanto, a resposta à sua pergunta é que não há espaços extras quando o código é executado porque o código é pré-compilado, portanto, NÃO PODE afetar a velocidade.
Eu acho que Correto-por-construção é realmente muito legal. É o melhor de um interpretador de tempo de execução e um compilador rápido em um só!
O parser na linguagem de computador Forth fez algo semelhante, em como funcionou, mas é claro que não tinha o correto pelo editor de construção. Eu sempre esperei adicionar um a ele.
Para a maioria das situações práticas, não deve ter impacto algum.
Você faria bem em considerar o uso de espaços e comentários não para desempenho, mas para legibilidade.
O VBA é uma linguagem interpretada, o que significa que o interpretador deve analisar todo o seu código legível toda vez que ele é executado, ao contrário de uma linguagem compilada na qual o código legível é compilado uma vez em código legível por máquina. Em ambos os casos, o espaço em branco & os comentários são removidos antes da execução.
Teoricamente, você poderia colocar bastante espaço em branco extra e / ou comentários em seu código VBA que acabaria atrasando o interpretador, mas provavelmente teria que ter milhares ou 10s de milhares de linhas de lixo extra ali para sempre note a diferença.Seria uma experiência interessante!
Tags vba microsoft-access-2003