Disadvantages of using Subs?

[Rattrapmax6]

Heh, nevermind, guess it does slow down.. I never clocked it.. :wink:

Yeah, the more lines of code slow it down also (I've noticed this one :wink: ),. so like the others siad, using SUBs to cut down on lines will balance it out..

[Spotted Cheetah]

As Z!re said subs take time, but they make the code and the EXE smaller, and easier to handle. I think usually writing a SUB worth if you have more than 3 lines of code what you want to put in it. You have to find the best point between making the code small, or making it fast. A good practice might be to write the subs, finalize them so they will not have anything to change in them, then look at the speed - critical parts of your code. There insert the smaller subs directly, what will gain some speed, but i think that would be only effective (only worth) if those subs has less than 5 lines. If they are long the gained time will simply get lost because it is only a small fraction of the overall time spent by the part's execution. Of course not just the number of lines count: for example if one of the lines is a GET capturing the entire 320*200 screen then the sub execution's time will be lost behind that GET's execution time. So plan the things wisely, that's the only thing what i can say. Or if you are not sure, test the speeds. There is one little advice left: if you insert a sub by code somewhere, you might comment that to remember it if you rewrite that. This might save you a few hours or days of bug hunting.

[Moneo]

If you're concerned with speed, you could use GOSUBs instead of SUBs, unless you really need the parameter-passing capabilities of SUBs and the use of local variables. The same can be said about using GOSUBs instead of FUNCTIONs.

If speed is not an issue, especially in an I/O intensive program, then use whatever is more intuitive and comfortable for you.
*****

[marzecTM]

converting subs back to non subs is the last, veryy veryyyy last step in optimization. besides this test

for i = 0 to 100000
a = a + 1
next i

for i = 0 to 100000
call testsub()
next i

sub testsub
a = a + 1
next sub

will never be fair. first of all you push and pop stuff to the stack like hell ( in that case the return adress of the sub. and you do this a lot of times here. second thing is you would really write the loop to the sub not having the loop calling the sub.

as a rule of thumb: write your code so it works no matter wheter its fast, then start on improving the algos in it, and as a last step do such nasty stuff as z1re stated it e.g. loop unrolling etc.

and most of all, if you want speed then don't use qb

[anarky]

Another thing with speed, why worry? Just go and buy a faster computer. If everyone else can't keep up, that's their problem. :lol:

[SJ Zero]

Barring that, ether write, or wait for someone to write, an inline keyword for fb.

Might not be as great as you think though.

[Mitthrawnuruodo]

Another thing with speed, why worry? Just go and buy a faster computer. If everyone else can't keep up, that's their problem. :lol:

A: It betters your programming skills when you need to make something faster on a fast compiler. Also with that attatude no ones going to want to use your programs...isn't that what they were made for? So its counterproductive,

[anarky]

Again, you're... confusing.

I was kidding! Get used to that. It's my smartarse nature but I mean no offence by it. Pay attention to the smilies i leave lying around. If there is no smiley, I mean business.

>anarky