wesweeks
asked on
Subs vs. Functions
I've recently inherited a VB project that has been in development for over a decade. My question concerns performance of Subs vs. Functions. All procedures are defined as Functions whether or not anything is returned.
Also Note:
No Public or Private scope set (Public By default)
No Return type (Does it default to Variant? Is it wasting resources?)
Here is a typical Example showing the syntax:
Function SumFunction()
'do Stuff
'SumFunction is NOT set to anything
End Function
There is a significant number of these functions (100's) that are declared this way. If I were to correct the above example, it would be like this:
Public Sub SumFunction()
'do stuff
End Sub
Is it worth my time and effort to correct these? Is there any performance benefit to converting these functions that don't return values to Subs?
Thanks for the input,
Wes
Also Note:
No Public or Private scope set (Public By default)
No Return type (Does it default to Variant? Is it wasting resources?)
Here is a typical Example showing the syntax:
Function SumFunction()
'do Stuff
'SumFunction is NOT set to anything
End Function
There is a significant number of these functions (100's) that are declared this way. If I were to correct the above example, it would be like this:
Public Sub SumFunction()
'do stuff
End Sub
Is it worth my time and effort to correct these? Is there any performance benefit to converting these functions that don't return values to Subs?
Thanks for the input,
Wes
If nothing is returned, no processing occurs.. hence you will receive no benefit from changing it to SUBs The function above is taking the default {Public} no gain here either... It's just a case of ugly code!, big problems when you try to convert to .net though
If a function is declared to return a boolean but in the function it is not returning anything, it will return false. If a function is declared to return a string but in the function it is not returning anything, it will return vbNullString. And so on.... Just ugly code. Change it to Sub since it is not return anything.
hongjun
hongjun
Change them to Sub.
If you don't explicitly name the type of variable returned in a function, it returns a Variant (the biggest data type at around 16 bytes).
Although you will not see an increase in speed until you hit millions of method calls, every little helps.
Why bother returning anything when you don't need to?
If you don't explicitly name the type of variable returned in a function, it returns a Variant (the biggest data type at around 16 bytes).
Although you will not see an increase in speed until you hit millions of method calls, every little helps.
Why bother returning anything when you don't need to?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Below is output from Numega TrueTime. The left column is the amount of time the operation took in milliseconds. The right column is the code itself. As you can see, calling Test1 (a variant function) takes 2 milliseconds longer per 1000 times being called. Basically, there is little benefit of making the change.
Option Explicit
0.6771 Function Test1()
54.4966 Me.Print "Hello"
1.0134 End Function
0.5872 Sub Test2()
54.0923 Me.Print "Hello"
0.8992 End Sub
0.0072 Private Sub Form_Click()
Dim i As Long
0.2376 For i = 1 To 1000
56.1652 Test2
Next i
0.0636 For i = 1 To 1000
58.1320 Test1
Next i
0.0004 End Sub
Option Explicit
0.6771 Function Test1()
54.4966 Me.Print "Hello"
1.0134 End Function
0.5872 Sub Test2()
54.0923 Me.Print "Hello"
0.8992 End Sub
0.0072 Private Sub Form_Click()
Dim i As Long
0.2376 For i = 1 To 1000
56.1652 Test2
Next i
0.0636 For i = 1 To 1000
58.1320 Test1
Next i
0.0004 End Sub
The main benefit of correcting these are your own piece of mind as you delve into the code.
We're working on a similar project started in VB3 where all non-local variables were defined as global (because that's all you had.) I'm painstakingly converting those to either module-level or, in some cases, local because of the problems that have occurred in the program where a global variable is inadvertently changed in the wrong place.
Also, setting procedures to private will have the benefit of not having them included in the "Intellisense" list that shows up when you reference the object.
And sub vs. function: If you know it doesn't return anything, sub is more appropriate, but I don't really see any benefit (other than those minimal time savings mentioned) to switching it at this point.
We're working on a similar project started in VB3 where all non-local variables were defined as global (because that's all you had.) I'm painstakingly converting those to either module-level or, in some cases, local because of the problems that have occurred in the program where a global variable is inadvertently changed in the wrong place.
Also, setting procedures to private will have the benefit of not having them included in the "Intellisense" list that shows up when you reference the object.
And sub vs. function: If you know it doesn't return anything, sub is more appropriate, but I don't really see any benefit (other than those minimal time savings mentioned) to switching it at this point.
ASKER
I got great advice from many people very quickly. It's too bad you have to select only one person to receive the points. Basically, the answers supported the conclusion that I had reached on my own, but I wanted to be sure. Thanks to everyone for the great advice.
Wes
Wes
One more thing - for those functions that Do return values, you should definitely Type the returns. A Variant uses extra memory, and extra processing time when returning a value to a typed variable
Public
======
Functions or Subs defined as Public will mean that it will be global and all modules, forms, etc will be able to use this function or sub. Use it if this function or sub is commonly used throughout the project.
Private
=======
This is the opposite of Public. If defined as Private, it can only be accessed by functions or subs in the same module or form. Functions or subs in another module or form will not be able to access it. Use this to minimize resources usage.
When to use Functions or Subs???
Use functions if you need to return something. Below is a private function that will return a boolean value.
Private Function Fun1() As Boolean
''''
Fun1 = True ' Return true value
End Function
Use Subs when you do not need to return a value. Below is a private sub.
Private Sub procedure1()
'
End Sub
When you see something like this without Private or Public declaration, then that's means it is Public
Function Fun2()
End Function
Sub procedure2()
End Sub
If a function does not declare a return type, then that means it is of Variant type. This means ANY type. It can return a boolean, string, integer, etc. However, this will result in more memory usage in order to carter for the various numerous return type size possibilities.
hongjun