# Visual Basic > Visual Basic 6 and Earlier >  VB6 Compiler Question: Do subroutines slow execution?

## yereverluvinuncleber

I have a fast executing animation that consists of a hundred or so lines of code and I wanted to tidy it up for readability's sake into five or six subroutines according to function, calling each in turn as needed... 

Does the addition of these subroutines (containing the same code) reduce the final execution speed or rather does it create an additional overhead? 

Alternatively, when compiled do these subroutines simply evaporate at runtime and the code becomes sequential?

Probably a noob question for those who understand compilers and the code they build. My guess is that it may be the latter but if anyone here can confirm, I would appreciate the benefit of your knowledge.

----------


## VanGoghGaming

While a few "subs" won't make a visible difference, when they start to pile up in tight loops then you might see a bit of a slowdown. When you execute a "sub" the program has to save the current state of the registers on the "stack" and then restore them when the subroutine ends. Transferring parameters between "subs" is also done back and forth through this ubiquitous "stack"... The "subs" also exist in compiled code, at machine code level they are translated into jumps back and forth through the code at various offsets in memory.

----------


## baka

the problem is not loops, sub calls etc, 
what will make it slow is calculations and rendering.
I use a game-loop
and theres hundreds of calls each "frame" and its a 60 (or more) calls a second with numerous animations and calculation and the CPU show from 0 to 3% depending on how heavy the map is.
so its not much.

the importance is "pre-work" here. so that your loop is as clean possible. but it doesnt matter if u call 30 subs. we are talking microseconds.
its what those subs contains and what u are doing.

and of course, avoid mistakes, like letting your picturebox refresh, or doevents or other events that gets could slow things down.

----------


## Lord Orwell

These answers are all correct.  The takeaway is subroutines do "technically" require some processing, but they are less intensive than poorly written code, and they are absolutely necessary if you are doing the same thing in many locations.  You absolutely, ABSOLUTELY don't want repeated code.  If you have it, you will eventually introduce a bug when you fix one routine and not the other.  This also applies to string constants.  In a web page?  You're referencing a specific control, that control's id needs to be in a variable if you're reading it in more than one location, which you automatically are because you named it in one place and referenced it in another.  This prevents errors from typos and capitalization.

----------


## Elroy

Said differently, if it's a procedure (i.e., what you call "subroutine"), if more than just a couple of lines of code, the overhead from a couple of PUSH and POP instructions is virtually negligible compared to what the procedure is actually doing.

Also, if you're really worried about it, and you're passing strings, UDTs, or arrays, be sure to pass them ByRef so you're not loading up the stack.  Just remember, when passed ByRef, any changes made to arguments are handed back to the caller.

----------


## Elroy

One more thought on this ... if these "subroutines" are in an object, make sure you're reference to the object is *Early Bound* (with the object's procedures preferably declared as *Friend*).  Calling procedures in a *Late Bound* object actually may create a noticeable amount of slowdown.

----------


## VanGoghGaming

What's this trickery about "Friend" procedures? I thought those only made sense in public ActiveX classes.

----------


## Elroy

> What's this trickery about "Friend" procedures? I thought those only made sense in public ActiveX classes.


A Friend procedure can be seen outside the object (but within the project) but only for early-binding.  If you want to call a procedure on a late-bound object, it's got to be Public, and will jump through a few more hoops to get to the procedure.

ADDED:  To say a bit more, I don't often use late-bound stuff within a project, but I do occasionally.  One place is when I pass a form's ObjPtr to subclassing (not knowing the exact form), and then call back into the form (using the ObjPtr).  The fact that I don't know which exact form I've got requires me to use late-binding and Public procedures in the form.

ADDED2:  I just re-read your comment.  I *always* use Friend in the class of objects, unless I'm just absolutely required to use Public.  Friend is *much* better.

----------


## VanGoghGaming

That's what I was asking, WHY is "Friend" much better in bold letters even!

----------


## jpbro

Changes to Friend method signatures don't break binary compatibility, so that's one bonus. That said, I always try to use Private unless there's a reason to access a method from outside the class, then I use Friend unless there's a need to access a method outside the library.

----------


## Elroy

> Changes to Friend method signatures don't break binary compatibility...


And the reason why is that Friend procedures aren't ever exposed outside the project.




> ... I always try to use Private unless there's a reason to access a method from outside the class, then I use Friend unless there's a need to access a method outside the library.


Precisely.  In VB6 that should always be the rule.

VanGogh, did you get your answer?  It's basically a matter of scope.  Private procedures, seen only within the object.  Friend procedures, seen only within the project (must be early binding).  Public procedures, seen within the project and possibly outside the project (can be early or late binding).

Truth be told, if you use early-binding with a Public procedure, there's probably not much (if any) difference in call speed (but I'd need to test or disassemble to be absolutely sure).  But there will certainly be a difference in call speed between late-bound/Public and early-bound/Friend.

Another advantage of Friend is that you can pass UDTs are arguments, whereas you can't for Public object procedures.  Unless we want to get into all the nitty-gritty of using the IUnknown and IDispatch interfaces, I'm not sure how else to say it.

----------


## yereverluvinuncleber

> Also, if you're really worried about it, and you're passing strings, UDTs, or arrays, be sure to pass them ByRef so you're not loading up the stack.


Does this make a difference to speed? Creating new objects on the stack... I have always tried to define my vars correctly byVar and byRef according to their usage and scope but if it is quicker to define all the vars within the animation subroutines byRef then I will have to make a few changes.

----------


## VanGoghGaming

"ByRef" is the default in VB6 so you shouldn't bother specifying it explicitly. In fact "ByVal" is only needed for API functions declarations since many of them are not happy with parameters being passed "ByRef". There are some rare cases where you'd want a parameter declared "ByVal" in your own procedures and that's if you modify its value and don't want it passed back to the caller.

----------


## The trick

https://www.vbforums.com/showthread....=1#post5567231

----------


## VanGoghGaming

> VanGogh, did you get your answer?  It's basically a matter of scope.  Private procedures, seen only within the object.  Friend procedures, seen only within the project (must be early binding).  Public procedures, seen within the project and possibly outside the project (can be early or late binding).
> 
> Truth be told, if you use early-binding with a Public procedure, there's probably not much (if any) difference in call speed (but I'd need to test or disassemble to be absolutely sure).  But there will certainly be a difference in call speed between late-bound/Public and early-bound/Friend.
> 
> Another advantage of Friend is that you can pass UDTs are arguments, whereas you can't for Public object procedures.  Unless we want to get into all the nitty-gritty of using the IUnknown and IDispatch interfaces, I'm not sure how else to say it.


Yep, I'm sold! That should just about sum it all up. Most of it was already explained in MSDN under "Remarks" for Friend procedures: 

_"Public procedures in a class can be called from anywhere, even by controllers of instances of the class. Declaring a procedure Private prevents controllers of the object from calling the procedure, but also prevents the procedure from being called from within the project in which the class itself is defined. Friend makes the procedure visible throughout the project, but not to a controller of an instance of the object. Friend can appear only in form modules and class modules, and can only modify procedure names, notvariables or types. Procedures in a class can access the Friend procedures of all other classes in a project. Friend procedures don't appear in thetype library of their class. A Friend procedure can't be late bound."_

I guess the "matter of scope" as you put it is neither an advantage nor a disadvantage, just a matter of choice. Since I never developed ActiveX components for somebody else to use, I guess the scope didn't matter for me, my procedures were always either "Private" or "Public".

However, the fact you can use "Friend" procedures with UDT parameters in "Standard EXEs" is something very useful for sure (and undocumented as far as I could tell!). Just tested it and it works fine!

Also the fact that "Friend" procedures don't break binary compatibility for ActiveX components when you change their parameters is a nice perk as well!

----------


## The trick

> I guess the "matter of scope" as you put it is neither an advantage nor a disadvantage, just a matter of choice. Since I never developed ActiveX components for somebody else to use, I guess the scope didn't matter for me, my procedures were always either "Private" or "Public".


Often it needs to have a getter property but a setter should be unavailable for a client. The Friend property does it. For example your class have a collection of sub-objects so these sub-objects should provide Parent property for client but shouldn't allow to set Parent property. So you can make Property Get as Public and Property Set as Friend. Outside the project the friends properties are not visible.




> However, the fact you can use "Friend" procedures with UDT parameters in "Standard EXEs" is something very useful for sure (and undocumented as far as I could tell!). Just tested it and it works fine!


This isn't undocumented. You can use a UDT with public method/properties too if the UDT is in a type library. Because of friend methods aren't accessible from outside of a project they don't require a type library for a UDT.

----------


## VanGoghGaming

Very good points, a day isn't wasted when you learn something new!

----------


## baka

I use mostly modules. Class I use as little possible. and I never use usercontrol. and as little components as possible. 
anything that is used in many places, will be public, that way I don't need to send anything around.
byref is almost never used with integer/long, only when theres a need for return
while string, byte, variant I always use byref if I will not "change" the variable inside the function.

readability is important I like my functions to be maximum 1 visible page. but surely, if needed I can have larger ones of course, sometimes its a most if theres a lot to do.

I hate class dependency or nested class dependency that uses classes that in the same time uses other classes. its a mess. hard to read and manage.
I also like simplicity. if I need math.mult() I dont want to have math.div() that is never used. that is why I avoid classes (if I dont create that myself)
so, everything in a class should be used. that for me is "readability" and easy to manage. so each project has its "adjusted" class. but, as I wrote, I avoid classes. modules is enough for everything.

also, as discussed in many places, modules "always" win when we are talking speed. 
so using classes is only about your own convenience and coding style, not because its "BETTER". 
if I import a class that someone else created (very seldom) I usually remove everything that is not needed.
most of the time, eventually I understand whats going on, and I rewrite it into a module and I also discover how "better" it is when in a module, and faster.

ok, this is maybe not exactly what OP asked. 
but for me the "calling a sub/function" is also how I construct the code, what I use, what I avoid, what I like, how I use it etc.

string and variants I try to avoid if possible. they are slower. byte array is better, so if possible I use that or safearray to reach the string.
I have data and showdata.
data is read-only where I have everything, while showdata is only what is visible.
instead of reading data when I show to user, I have a routing that will "create" the showdata one time. and a rendering-function that will only focus on showdata.
(of course if needed, if I just need to show a value, no need to create a showdata, it mostly involving sorting as well, or I need to fetch different things like RECT values, calculate position etc)

----------


## PlausiblyDamp

> I use mostly modules. Class I use as little possible. and I never use usercontrol. and as little components as possible. 
> anything that is used in many places, will be public, that way I don't need to send anything around.
> byref is almost never used with integer/long, only when theres a need for return
> while string, byte, variant I always use byref if I will not "change" the variable inside the function.
> 
> readability is important I like my functions to be maximum 1 visible page. but surely, if needed I can have larger ones of course, sometimes its a most if theres a lot to do.
> 
> I hate class dependency or nested class dependency that uses classes that in the same time uses other classes. its a mess. hard to read and manage.
> I also like simplicity. if I need math.mult() I dont want to have math.div() that is never used. that is why I avoid classes (if I dont create that myself)
> ...


This is a genuine question and not intended to be a criticism in anyway... What makes you choose VB6 as your language of choice? 

I am just wondering why you choose to code in VB6 when you seem to be avoiding the vast majority of what the language and runtime give you. If you are going to code in a very procedural style, no classes or objects, global variables, avoiding strings in favour of byte arrays / safearrays, use of byref etc. Also a lot of your other posts are using CopyMemory, GetMem etc. It just seems odd to choose a language and avoid most of what it does, it almost seems that you are using VB6 to code in a manner more like a traditional C procedural program rather than VB6.

----------


## Schmidt

> I avoid classes. modules is enough for everything.


Good lord, ... baka! 
That's wrong on so many levels, I don't even know where to start.

Classes are your "knights in shining armor, who keep the spaghetti-monsters at bay".

If you "under-use" them (no matter if you develop a game, or a "normal GUI-App"),
you do yourself a disservice (with regards to maintainability).

And no, even if you bring up "plain C" as the big example,
 "what's possible with only procedural programming in flat-modules",
you're missing one important point:

C allows to place Functions (Function-Pointers) within its struct-definitions (its UDTs) -
which are later on *easily* callable from "within a given UDT-allocation of that kind".

VB6/VBA-modules do *not allow to call* (with ease) -
"function-pointer-members, defined within an UDT" (as the "most basic definition of a Class").

Olaf

----------


## Schmidt

> ...
> it almost seems that you are using VB6 to code in a manner more like a traditional C procedural program rather than VB6.


Yep, have suggested FreeBasic to him already years ago, where:
- 90% of all his VB6-"UDT-defs and Flat-Functions" would work out of the box
- then compilable to 32Bit/64Bit x86 (on Windows/Linux) 
- or even ARM64

And regarding my post above, FreeBasic is similar to "plain C" in,
that it allows to "use Function-Pointers in User-Type-Defs" in an even easier way, compared to C.

Olaf

----------


## yereverluvinuncleber

> "ByRef" is the default in VB6 so you shouldn't bother specifying it explicitly...


Gawd No. All my vars are declared byVal or ByRef explictily - all the time. Good typing is explicit and anything else is lazy. 




> and that's if you modify its value and don't want it passed back to the caller.


We all know this already, that wasn't the question asked.




> Also, if you're really worried about it, and you're passing strings, UDTs, or arrays, be sure to pass them ByRef so you're not loading up the stack.  Just remember, when passed ByRef, any changes made to arguments are handed back to the caller.


That was the statement that I needed clarification on. Does not loading up the stack really make a difference to speed?

----------


## Elroy

> That was the statement that I needed clarification on. Does not loading up the stack really make a difference to speed?


That's a good question, and I'm not sure I know the answer.  Basically, does doing a PutMem4 execute faster than an RtlMoveMemory of, say, 200 bytes?  I'd have to put together an empirical test to know for sure, but I'll leave that to you.  :Smilie:   It's certainly more memory efficient.

----------

This all reminds me of another small speedup:  Sub calls with a return argument are slightly faster than Function calls.  The reason is that a Function call has to move memory pointers around one more time (in assigning whatever variable the function's return goes into) than a Sub call.

The one place I've actually seen concern about this though is in The Trick's DirectX math procedures.  He did everything as Subs (no Functions) just to get that tiny extra bit of speed, knowing that those procedures were going to be used in high-performance loops.

----------

Also, just to quickly comment on using BAS vs CLS modules, I've gone back-and-forth on this through the years.  I do use lots of CLS procedures, but I've gotten to where I use them only when it makes good sense (and there's a good reason) to do so.  For a while (in the beginning of VB6) it seemed like *everyone* was insistent upon doing everything with CLS modules.  It sucked me in for a while, but not for long.  If they're general purpose procedures, there's just typically no need for a CLS (and its corresponding object).

Also, I think User Controls are wonderful (but again, only when truly called for).  Just a couple of examples that come to mind are:  OptionButton with a "group" property so that different "groups" don't require different containers; a vertical label; a ComboBox with different tooltip text for each dropdown item; etc etc.

----------


## Schmidt

> Good typing is explicit and anything else is lazy.


Well, in the few Code-Snippets I've seen you post here,
you (very lazily and "non explicitly") did assignments like this:
x = 123
instead of:
Let x = 123

Very curious now, how you'll dig yourself out of that...  :Wink: 
(keeping in mind, that there's other explicit assignment-prefixes like: LSet, RSet and Set)

Olaf

----------


## baka

not true at all Schmidt.
I have worked with usercontrols and classes. a lot. I have been coding for +20 years.
during this time I learned the "hard way" all the "issues" we have with usercontrols and classes.
I have converted many times classes into pure modules just because of issues that "came later".
stuff that I couldn't do, because they where locked inside a class. all the extra turns to fix that.
I have also used "classes" that I downloaded from here. where I need to have 10 classes to just use GDI+
guess what. I have a single module that do "EXACTLY" what I need and MORE
while that GDI+ classes project is so big I dont even know where to start to "improve it" to make it work for my needs.
the only way is to deconstruct it all and insert parts that I need. and I mean. its HELL.
better to start over.

and its eeeeextremely easy to maintain a project with just modules. at least for me.
each module has is purpose. even if there could be communication between the modules its easy to follow and fix.
bugs are easy to find this way.

right now Im working with a "special" project for my game. and Im in my "version3" because I was not happy with 1 & 2
and what I do is to start over, but I can use functions from ver1,2 easily. since those can be used anywhere.
if a class. usually its coded in a way, that I always need to convert it to make it use in a module.
and if I need to "redo" a class. its start over most of the time, everything is wasted.

I have multiple modules that I can use in ANY project, that I can choose what to take.
that is why I dont like classes.

I see many people code here. and its a mess.
and if they don't know how it works it will eventually bite them, they don't understand the class they are using so when bugs start to popup, its game over.
sure, for u "masters" here, u can always revise it and update it. but for the common person it means game over. it means asking for help or abandon it.

I have tried a couple of classes they didnt even RUN. coudln't start it. and where should I even start? its nested and made in a bad way that is hard to read.
some people code in a strange way. I like simplicity.

u think u know it all. that your way is the only way and the way it should be.
but guess what. its not. I have been coding for years and this is EXACTLY how I like it and Im comfortable and I can maintain it and EASY fix bugs.

and again. I have written this before. VB6 is not components/usercontrols its a programming language and u can use it how u want.
I mean. u can't say. "PUTMEM4" is not VB6. if it was not, I wouldn't be able to use it. 
PUTMEM4 is as much valid as a class. BUT its your choice what u want to use.
if I don't want to add a microsoft rich textbox control and instead create my own textbox using my own solution, ITS AGAIN. a choice. if I can do it, it means its VALID.
so don't come here and tell me HOW I should do. its my own decision. as much its your decision to use usercontrols, components and whatnot. its not MY place to tell u want u do.

what we do here is SHARING. meaning. u do like this, and u do like that, while I do in this way. and all are valid. 
after that we could discuss optimization, speed, readability etc. of course. some code is better than other. BUT again, its not your place to tell how someone should write. its up to them.

so, I code like this and "I FIND" a way that "WORKS" for me. I start +20 years so I know how "I WORK" and what I enjoy. call me whatever or that Im a noob programmer. but thats me.

----------


## yereverluvinuncleber

> you (very lazily and "non explicitly") did assignments like this:
> x = 123
> instead of:
> Let x = 123
> 
> Very curious now, how you'll dig yourself out of that...


I won't try to dig myself out of it. In fact, I will admit to it as I just encountered just such a bug 5 minutes ago. I tend to write dirty code at first, create tests for that dirty code - and then tidy it up later. 

Writing javascript for so long leads you astray... However, I do use Rubberduck (mostly switched off) when I have something to deliver and at some point I try to fix everything I can. 

option explicit improves things but it does not prevent integers taking values from vars typed as strings:

intShowCmd = sShowCmd ' where sShowCmd should always be "0" and "1" but when undefined it falls over in a heap. One of my typical feck ups.

In addition I was taught by another VB6 expert not to use LET anymore and in .NET/.js it is not really used. So I got in the hang of leaving it out. 

LET has its place and I think it would have caught the above.

Regardless, it does not suggest that my use of byVal or byRef is deficient.

----------


## vb6forever

> Elroy's Comment post #23
> 
> Also, just to quickly comment on using BAS vs CLS modules, I've gone back-and-forth on this through the years. I do use lots of CLS procedures, but I've gotten to where I use them only when it makes good sense (and there's a good reason) to do so. For a while (in the beginning of VB6) it seemed like everyone was insistent upon doing everything with CLS modules. It sucked me in for a while, but not for long. If they're general purpose procedures, there's just typically no need for a CLS (and its corresponding object).
> 
> Also, I think User Controls are wonderful (but again, only when truly called for). Just a couple of examples that come to mind are: OptionButton with a "group" property so that different "groups" don't require different containers; a vertical label; a ComboBox with different tooltip text for each dropdown item; etc etc.


I came to the same conclusion years ago, also.
 Use very little classes AND ONLY when needed.
Part of this may be LACK of NEED of CODE REUSE.   Normally most things I do are one offs.

--------------
I think everyone forgets there are about 2500 different languages to choose from.  Each has their plus and minuses.  The majority were created not to benefit the programmer, but to compete with some other language and generate revenue for the developer.
The old Windows 98 Programming book which was some form of "C" --as I recall-- offered a lot of advantages even over VB5/6 as its syntax was easy to understand and mostly API based.
My2Cents

----------


## PlausiblyDamp

> I have also used "classes" that I downloaded from here. where I need to have 10 classes to just use GDI+
> guess what. I have a single module that do "EXACTLY" what I need and MORE
> while that GDI+ classes project is so big I dont even know where to start to "improve it" to make it work for my needs.
> the only way is to deconstruct it all and insert parts that I need. and I mean. its HELL.
> better to start over.


That to me sounds like a problem with project, not with classes themselves. Proper class design is important, too many classes is a sign of poor design.




> right now Im working with a "special" project for my game. and Im in my "version3" because I was not happy with 1 & 2
> and what I do is to start over, but I can use functions from ver1,2 easily. since those can be used anywhere.
> if a class. usually its coded in a way, that I always need to convert it to make it use in a module.
> and if I need to "redo" a class. its start over most of the time, everything is wasted.


Again, if you have a class that can't be reused then I would say that is apoor design, not an issue with classes themselves.




> I have multiple modules that I can use in ANY project, that I can choose what to take.
> that is why I dont like classes.


There is no reason why well designed classes can't be used in multiple projects either.




> I see many people code here. and its a mess.
> and if they don't know how it works it will eventually bite them, they don't understand the class they are using so when bugs start to popup, its game over.
> sure, for u "masters" here, u can always revise it and update it. but for the common person it means game over. it means asking for help or abandon it.


Again, not specific to classes - people can write messy code with modules and fail to understand modules written by other people.




> I have tried a couple of classes they didnt even RUN. coudln't start it. and where should I even start? its nested and made in a bad way that is hard to read.
> some people code in a strange way. I like simplicity.


Again, if the classes are that badly designed it is an issue with the design rather than the use of classes.




> and again. I have written this before. VB6 is not components/usercontrols its a programming language and u can use it how u want.


Why choose a language when you avoid nearly all of the included language / runtime functionality though? Wouldn't it be better to choose a lanhuage that fits your approach to software design rather than trying to beat VB6 into fitting your approach?




> I mean. u can't say. "PUTMEM4" is not VB6. if it was not, I wouldn't be able to use it. 
> PUTMEM4 is as much valid as a class. BUT its your choice what u want to use.


VB6 allows you to call external functionality, putmem4 is external functionality - that is not the same as a fundamental construct built into the language itself. By your definition the entirety of the windows API and every COM object ever created is part of VB6 because VB6 can use it....




> so, I code like this and "I FIND" a way that "WORKS" for me. I start +20 years so I know how "I WORK" and what I enjoy. call me whatever or that Im a noob programmer. but thats me.


But why not choose a language that fits your style of coding rather than one that doesn't?

----------


## baka

I have, that is why I use VB6. not sure what u try to say.
its like saying if u dont code like me u should not use it.
what is the problem here? WHO has a problem? its not me for sure, and its not the first time people answer like this.
VB6 works for my needs. and when TB works like I want, I will use that. is there a problem?
why do I need to use another language?
and PUTMEM4 is part of VB6, u are using msvbvm60

it should be quite obvious.
1. I like Basic. its the best computer language if we are talking easy-to-read and code.
2. I like VB6 IDE. its well organized and simple.
3. It com-based and can compile in native-code. 
4. I can create EXE without any dependency. it can run without any installation/registration. people can just download the EXE and run it.
5. theres TONS of samples/code and we have a good forum. so we can still learn.
6. theres some good people that still work to improve it.
7. TB is in the making that will in the future provide cross-platform. 
8. I know VB6 quite well (for my level) and I improve all the time, this is good to have when I eventually move to TB and 64bit/CrossPlatform.

any questions?

----------


## Schmidt

> what is the problem here?


The problem is -
that you try to convince "all other owners of the same car-model with manual gear-shifting":
- that they are well-advised, to "drive this car around only in first gear"
- and that "the clutch" should only be used, to get the car out of stand-still

Then you try to underline this statement with the fact, that you were:
- "visiting your 100m distant bakery this way without fail, for the last 20years".

Then, when other guys who use this car-model as well, mention to you that -
"the car has more than one usable gear and is able to move more efficiently",
you deal out the "insufferable know-it-all card".

Funnywise followed in your recent posting by: "this is a good forum, where we all can learn".

Well, I for my part hope that others who read this have taken away at least, 
that "driving around only in 1st gear exclusively" is not a good idea.  :Wink: 

Olaf

----------


## baka

omg. not sure what to say.
now u show very low intelligence here.
so I need to use a class and old component and even a  usercontrol or its not good enough?
come on, u can not be that narrow minded. O M G. 

O    M    G

its just pathetic, its so low level that is stupid. u know nothing about development if u really believe what u say
if u seek attention, again. pathetic. go get it somewhere else. I dont have time with narcissism.

----------


## yereverluvinuncleber

Right chaps, in the absence of a moderator, let's close this one off and lay off the insults, shall we?. Don't let it degrade as usual. This is my thread and I want it back on track. This was a VB6 compiler question asking whether subroutines slow execution and I think I have the answer and a few useful extra things to think about.

----------


## Shaggy Hiker

I liked the discussion up until it started going off the rails.

----------

