I posted this earlier today in the VB6 section but for those of you who don't read those threads I htought I would repeat it here...

I like GOSUB. I started programming in Assembly and Turbo Pascal back when PC's first came out in the early ‘80s so I have been doing this for a long time.

There are two main advantages of using GOSUB: 1) no variables to push/pop from the stack and 2) any local variables don't need to initialized and destroyed on each call.

The supposed disadvantages of using GOSUB are: 1) it just isn't modern coding practice, 2) it leads to spaghetti code that is very hard to use and maintain, 3) it is only like a Sub and it can’t return a value like a Function and 4) because of (1) and (2) most younger programmers don’t even know when/how to use it and most “modern” programming languages don’t even include it.

Processors use gosub internally. They also use a lot of what is the equivalent of the GOTO command in VB/VBA but that is a discussion for another day.

I also find that GOSUB doesn’t make me write spaghetti code (at least any more than I do without using it). I can find a line label in my current procedure as fast as I can find a standalone routine and with proper commenting I dno’t hae any additional code maintenance issues.

I keep reading statements by other programmers about their disdain for GOSUB but their arguments are weak to non-existent for why we shouldn’t use it and why it made sense for Microsoft to remove it from VB.NET. I think that’s crazy so I decided I would test my assumptions regarding speed.

I worked up something approximating a real-world scenario and I wrote a simple program that call the repeating code via a Function and I wrote another routine that called the repeating code via a GOSUB command.

I got some very surprising results. Below are the time in milliseconds to execute the code 10,000 times.

Using Function Using GOSUB
VBA 1,092 475
Un-compiled VB6 960 472
Compiled VB6 371 866
Compiled VB6 (p-code) 906 435


The code in VBA did about what I thought it would. This is basically like pseudo-code that can be “compiled” by VB6; it is not native machine code. The GOSUB code is 2.3 times faster.

Un-compiled VB6 is similar to VBA; the function calls are about 13% faster but the GOSUB code is only marginally faster than VBA although it is 2 times faster than the Function call code.

Using VB6 with code compiled to p-code was similar to un-compiled VB6 code but about 5-8% faster. I don’t use p-code for a variety of reasons but it is a bit faster than either VBA or un-compiled VB6. However, note that the GOSUB version is a bit more than 2 times faster like the other codings.

The surprise comes with code compiled to native machine code. BTW, the results were very similar when I optimized for small code or faster execution. As expected the use of the Function code was a bit over twice as fast. What was surprising was that the code using GOSUB was over 2.3 times as slow as the Function version and twice as slow as all of the other versions of the GOSUB coding for VBA, un-compiled VB6 and p-code VB6. Whoever did the compiler logic for GOSUB in VB6 did a horrible job!

So the bottom-line for me is that GOSUB is the way to go for VBA but programs using compiled VB6 to machine code will run faster with conventional Function or Sub calls.

I have the code and raw results available if anyone wants to play with them.