logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

follow us in feedly

Quando você usa o Visual Basic 6, você usa também o Visual C++ 6

Um belo dia estava eu em minha casa corrigindo um bug em um programa feito em Visual Basic. Esse é um programa que eu fiz quando ainda trabalhava como desenvolvedor autônomo (ou seja, além do emprego eu pegava trabalho por fora para fazer em casa), e a escolha óbvia era fazê-lo em Visual Basic 6.

Depois de corrigir os bugs, pedi gentilmente ao VB para que gerasse o executável. A IDE então me reportou que ouve um erro durante a compilação e, caso eu quisesse mais informações, que lesse um arquivo de log. Tamanha foi a minha surpresa quando abri o arquivo de log e me deparei com isso:

D:\DATA\blablabla\frmTabelas.frm(3398) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'E:\8783\vc98\p2\src\P2\main.c', line 494) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information

Pelo que parece, o Visual Basic 6 usa pelo menos uma parte do backend do compilador do Visual C++ 6.0. Talvez isso explique um comparativo de performance que deixou algumas pessoas chocadas, onde um componente feito em Visual Basic 6 ficou quase 3 vezes mais rápido do que um feito em C#. O fato do VB6 usar o backend do VC6 é uma boa explicação para isso.

Seria interessante ver uma nova comparação, mas dessa vez com o .NET 2.0. Na nova versão o JIT foi melhorado e o JIT 64 bits é feito pela equipe do Visual C++ - que é, de longe, a equipe da Microsoft que mais entende de otimização. Acredito que o VB6 ainda será mais rápido (não dá pra comparar código nativo gerado pelo backend do Visual C++ com código gerenciado) mas acredito - e espero - que a diferença nesse quesito seja menor.


Em 24/02/2006 17:14, por Rodrigo Strauss


  
 
 
Comentários
Alfred Gary Myers Jr. | website | em 24/02/2006 | #
"Talvez isso explique um comparativo de performance que deixou algumas pessoas chocadas, onde um componente feito em Visual Basic 6 ficou quase 3 vezes mais rápido do que um feito em C#. O fato do VB6 usar o backend do VC6 é uma boa explicação para isso."

Não... Não é uma boa explicação.
O motivo pelo qual o VB6 é tão mais rápido que o Enterprise Services (o managed wrapper do COM+ e não o C# ou o VB.NET) em um único exercício do referido artigo, é que o ES na versão 1.x faz chamadas extras na criação e destruição dos objetos.
E isto tem um peso considerável em chamadas in-process.
O peso destes round-trips diminui consideravelmente quando as chamadas passam a ser feitas out-of-process ou cross-machine.

Também não adianta esperar pela nova versão do JIT, já que no artigo se está lidando com JITA (Just in Time Activation) do COM+/Enterprise Services e não JIT Compilation.


Rodrigo Strauss | website | em 25/02/2006 | #
No teste onde o VB6 fica quase 3 vezes mais rápido do que o C#, não existe o overhead de criação de objetos citado no artigo, já que:

"...number of calls per second made against a trivial method... Most of the cost of activating and releasing the object is gone, but the cost of delivering the call is still there"

Sendo assim, "chamadas extras na criação e destruição dos objetos" não tem peso algum no teste citado. O que domina é marshal/unmarshal de parâmetros e velocidade do código envolvido (principalmente no caso in-process, que exclui os fatores rede e shared memory). Claro que no caso das linguagens .NET o cruzamento da fronteira managed/unmanaged deve ter um peso, já que o COM+ é todo C++/unmanaged.

Talvez o JIT não seja a explicação exata para esse problema, mas é um ponto fraco (que como eu disse, talvez desapareça com o tempo). Como o JIT faz o seu trabalho enquanto o usuário está esperando, ele não pode se dar ao luxo de fazer todas as otimizações que o backend do Visual C++ faz. Se pudesse, era só adaptar o backend do VC no JIT e tudo se resolveria. E um código com uma otimização melhor sempre será mais rápido.

Além disso é interessante notar o quarto gráfico (que parece ser onde o autor queria chegar), onde todas as linguagens ficam praticamente empatadas, já que a maioria do tempo gasto na chamada envolve banco de dados e rede, o que faz com que, percentualmente, a diferença de perfomance entre as linguagens/runtimes desapareça.

Inclusive, tem uma coisa interessante nesse artigo: em nenhum momento o autor compara as linguagens .NET incluindo a criação e destruição dos objetos a cada chamada, como ele fez com VB e C++....
Júlio C. Brito | em 14/03/2006 | #
Na verdade, esse erro ocorreu em um módulo da mfc, no qual o VB6 foi desenvolvido(o VB foi desenvolvido em c++, no visual c++). Não possui relação nenhuma com o compilador do vc++.
Rodrigo Strauss | website | em 14/03/2006 | #
Acho que você fez confusão... Não tem nada de MFC no Visual Basic, o VB6 é feito em C++ puro e usando um embrião da ATL (que foi criada pela equipe do Visual Basic).
Algo a dizer?
Nome:


Site:


E-mail:


Escreva o número vinte e seis:


 Não mostre meu e-mail no site, não serve pra nada mesmo...

Comentário





Os comentários devem ser sobre assuntos relativos ao post, eu provavelmente apagarei comentários totalmente offtopic. Se quiser me enviar uma mensagem, use o formulário de contato. E não esqueça: isso é um site pessoal e eu me reservo o direito de apagar qualquer comentário ofensivo ou inapropriado.
rebarba rebarba
  ::::