Rodrigo Strauss :: Blog
|
|
|
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 11:14
"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.