Correctly written Visual Basic code can easily outperform poorly written C code. This is especially true with Visual Basic 5. (Visual Basic 5 native code is faster than p-code.) Whatever language you use, apply the correct algorithm.
At times, of course, you might have to use other languages, say, to gain some required speed advantage. One of the truly great things about Windows (all versions) is that it specifies a linkage mechanism that is defined at the operating system level. In MS-DOS, all linkages were both early and defined by the language vendor. The result was that mixed-language programming was something only the very brave (or the very foolish) would ever have attempted. It used to be impossible, for example, to get some company’s FORTRAN compiler to produce object files that could be linked with other object files generated by another company’s C compiler. Neither the linker supplied with the FORTRAN compiler nor the one that came with the C compiler liked the other’s object file format. The result was that mixed-language programming was almost impossible to implement. This meant, of course, that tried-and-tested code often had to be ported to another language (so that the entire program was written in one language and therefore linked).
Trouble is that these days we’ve largely forgotten that mixed-language programming is even possible. It is! Any language compiler that can produce DLLs can almost certainly be used to do mixed-language programming. For example, it’s now easy to call Microsoft COBOL routines from Visual Basic. Similarly, any language that can be used to create ActiveX components can be used to create code that can be consumed by other, language-independent, processes.
At The Mandelbrot Set (International) Limited (TMS), when we really need speed—and after we’ve exhausted all the algorithmic alternatives—we invariably turn to the C compiler. We use the existing Visual Basic code as a template for writing the equivalent C code. (We have an internal rule that says we must write everything in Visual Basic first—it’s easier, after all.) We then compile and test (profile) this code to see whether the application is now fast enough. If it’s not, we optimize the C code. Ultimately, if it’s really required, we get the C compiler to generate assembly code, complete with comments (/Fc and /FA CL.EXE switches are used to do this), and discard the C code completely. Finally, we hand-tune the assembly code and build it using Microsoft’s Macro Assembler.