Function vs Sub /Public vs Private

[lauren quantrell]

I'm hoping someone can tell me if there is any performance benefit in
my applications between distinguishing a code routine as a Function or
a Sub or if there is a performance benefit between identiying a
Function as a Function or a Private Function (or Sub as a Sub or a
Private Sub) in code modules.

I understand that using Private Functions or Private Subs limits the
scope from which it can be called, but I'm wondering if there is any
speed or overhead benefit in making the distinction.

I know I can't call a Sub using "=SubName() " in the event procedure of
a control, only = "=FunctionName( )", so I just got in the habit of
labeling everything as a Function instead.

Thanks,
lq

[Steve Jorgensen]

Re: Function vs Sub /Public vs Private

On 18 Jul 2005 08:44:53 -0700, "lauren quantrell"
<laurenquantrel l@hotmail.com> wrote:
[color=blue]
>I'm hoping someone can tell me if there is any performance benefit in
>my applications between distinguishing a code routine as a Function or
>a Sub or if there is a performance benefit between identiying a
>Function as a Function or a Private Function (or Sub as a Sub or a
>Private Sub) in code modules.[/color]

If a value is not being returned, a Sub should be a tiny bit more efficient
than a Function, but I doubt you'll ever notice the difference. Public vs
Private should not be expected to make any difference at all since it's only a
rule, checked at compile-time.
[color=blue]
>I understand that using Private Functions or Private Subs limits the
>scope from which it can be called, but I'm wondering if there is any
>speed or overhead benefit in making the distinction.[/color]

There shouldn't be.
[color=blue]
>I know I can't call a Sub using "=SubName() " in the event procedure of
>a control, only = "=FunctionName( )", so I just got in the habit of
>labeling everything as a Function instead.[/color]

I consider that poor style (but that's a matter of taste), but I doubt there's
any noticeable performance penalty.

[lauren quantrell]

Re: Function vs Sub /Public vs Private

Steve,
Thanks for the reply.

Poor Style refering to labeling everything as a Function instead of a
Sub or Poor Style using =FunctionName() in the event procedure of a
control?

thanks,
lq

[David W. Fenton]

Re: Function vs Sub /Public vs Private

"lauren quantrell" <laurenquantrel l@hotmail.com> wrote in
news:1121702442 .955212.309550@ z14g2000cwz.goo glegroups.com:
[color=blue]
> Poor Style refering to labeling everything as a Function instead
> of a Sub or Poor Style using =FunctionName() in the event
> procedure of a control?[/color]

If it's a function, it should be a function.

If it's not, it should be a sub.

Sounds axiomatic, but making every code snippet you write a function
is abdicating your responsibility as a programmer for evaluating the
purpose and use of the code you are writing.

To me, the default is to make a SUB.

You only write a function when you *must*:

- if you must return a single value

- if the code needs to be called in contexts where only functions
work (i.e., macros, etc.).

If you write a sub and later need to use it as function, it's about
1 second's work to change it to a function.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[lauren quantrell]

Re: Function vs Sub /Public vs Private

David,
Thanks for that but I have to ask, is there any difference in overhead
or performance with having every code snippet a function vs. a sub and
how in evaluating the code will it make a difference? I'm not trying to
be difficult, just trying to decide why and to who it would make any
difference.
Thanks,
lq

[Rick Brandt]

Re: Function vs Sub /Public vs Private

lauren quantrell wrote:[color=blue]
> David,
> Thanks for that but I have to ask, is there any difference in overhead
> or performance with having every code snippet a function vs. a sub and
> how in evaluating the code will it make a difference? I'm not trying
> to be difficult, just trying to decide why and to who it would make
> any difference.
> Thanks,
> lq[/color]

Try it. Run a sub in a loop a few hundred times and then run the same code as a
function and see if there's a difference. My guess would be no, but it would
just be a guess.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Trevor Best]

Re: Function vs Sub /Public vs Private

Rick Brandt wrote:[color=blue]
> lauren quantrell wrote:
>[color=green]
>>David,
>>Thanks for that but I have to ask, is there any difference in overhead
>>or performance with having every code snippet a function vs. a sub and
>>how in evaluating the code will it make a difference? I'm not trying
>>to be difficult, just trying to decide why and to who it would make
>>any difference.
>>Thanks,
>>lq[/color]
>
>
> Try it. Run a sub in a loop a few hundred times and then run the same code as a
> function and see if there's a difference. My guess would be no, but it would
> just be a guess.
>[/color]

sub is a second faster... after 10,000,000 calls :-)
as an aside, using "call" doesn't make a damn.

Output of code (code below sig)
***
Sub Direct Call: 1.5625
Func Direct Call: 2.671875
Sub Call: 1.625
Func Call: 2.671875

--
[OO=00=OO]

Sub testsubvfunctio n()
Dim s As Single
Dim i As Long
Const clngTimes As Long = 10000000

Debug.Print "***"

s = Timer
For i = 1 To clngTimes
testsub
Next
Debug.Print "Sub Direct Call: " & Timer - s

s = Timer
For i = 1 To clngTimes
testfun
Next
Debug.Print "Func Direct Call: " & Timer - s

s = Timer
For i = 1 To clngTimes
Call testsub
Next
Debug.Print "Sub Call: " & Timer - s

s = Timer
For i = 1 To clngTimes
Call testfun
Next
Debug.Print "Func Call: " & Timer - s


End Sub
Sub testsub()
Dim a As Long
a = 1
End Sub
Function testfun()
Dim a As Long
a = 1
End Function

[james.igoe@gmail.com]

Re: Function vs Sub /Public vs Private


Not being dogmatic, I've started running many procedures as functions,
returning a boolean or text. This has improved my program control and
error tracking, since, if the function procedure fails, it returns a
value to the originating routine, allowing me to code for errors, as
well as giving better programmatic control.

[Steve Jorgensen]

Re: Function vs Sub /Public vs Private

On 19 Jul 2005 04:53:50 -0700, "james.igoe@gma il.com" <james.igoe@gma il.com>
wrote:
[color=blue]
>
>Not being dogmatic, I've started running many procedures as functions,
>returning a boolean or text. This has improved my program control and
>error tracking, since, if the function procedure fails, it returns a
>value to the originating routine, allowing me to code for errors, as
>well as giving better programmatic control.[/color]

That's sort of a C coding style. Isn't that what exceptions are for, though?
To not clutter the main line of execution with If statements to handle
non-mainline cases?

[lauren quantrell]

Re: Function vs Sub /Public vs Private

And to my original point, I use a lot of event procedures to call code
OnClick = "=RunSomeCoolCo de()" and these can't be called as subs but
they can be called as functions. In many cases the code called by an
event procedure on one form might also be called from an event
procedure or a command button on other forms. Codig it as a function in
one place streamlines the code and increases opportunities to use it
repeatedly throughout the application.
lq

[David W. Fenton]

Re: Function vs Sub /Public vs Private

"lauren quantrell" <laurenquantrel l@hotmail.com> wrote in
news:1121790387 .852296.121640@ g43g2000cwa.goo glegroups.com:
[color=blue]
> And to my original point, I use a lot of event procedures to call
> code OnClick = "=RunSomeCoolCo de()" and these can't be called as
> subs but they can be called as functions. In many cases the code
> called by an event procedure on one form might also be called from
> an event procedure or a command button on other forms. Codig it as
> a function in one place streamlines the code and increases
> opportunities to use it repeatedly throughout the application.[/color]

You seem to be arguing for an approach that I consider to be
brain-dead stupid. That is, you seem to suggest making every
subroutine a function *just in case* you should ever sometime
between now and the Apocalypse need to use it as a function.

That, to me, constitutes an abdication of one of the most important
jobs of a programmer: to fully consider the scope and use of code as
you're writing it. If you never ask yourself "should this be a sub
or a function?" you may end up not really considering important
issues regarding how the code you are writing is going to be needed,
in what contexts and for what purposes.

Secondly (to repeat myself). it's not like it's *hard* to convert a
subroutine to a function once the need to return a value comes up --
it takes all of one second.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[lauren quantrell]

Re: Function vs Sub /Public vs Private

I'm really trying to undertsnad this since others in this thread have
demonstrated how it makes no difference as far as speed or overhead.
So, how does limiting the scope of a bunch of code in a Sub make any
difference beween unlimiting it in a Function? I do make great use of
Private Functions vs. Public Functions to accomplish this.
lq

[David W. Fenton]

Re: Function vs Sub /Public vs Private

"lauren quantrell" <laurenquantrel l@hotmail.com> wrote in
news:1121811050 .406303.210760@ f14g2000cwb.goo glegroups.com:
[color=blue]
> I'm really trying to undertsnad this since others in this thread
> have demonstrated how it makes no difference as far as speed or
> overhead. So, how does limiting the scope of a bunch of code in a
> Sub make any difference beween unlimiting it in a Function? I do
> make great use of Private Functions vs. Public Functions to
> accomplish this.[/color]

Because asking yourself "should this be a function or a sub?" frames
the whole issue of what purpose the code serves.

The performance issue has ZILCH to do with it.

If I were picking up someone else's code and found everything was a
function, I'd be severely puzzled trying to figure out why, until I
figured out that it was just a misguided (or incompetent)
programmer.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

Re: Function vs Sub /Public vs Private

lauren quantrell wrote:[color=blue]
> And to my original point, I use a lot of event procedures to call code
> OnClick = "=RunSomeCoolCo de()" and these can't be called as subs but
> they can be called as functions. In many cases the code called by an
> event procedure on one form might also be called from an event
> procedure or a command button on other forms. Codig it as a function in
> one place streamlines the code and increases opportunities to use it
> repeatedly throughout the application.[/color]

To me, using OnClick = "=RunSomeCoolCo de()" in a property sheet is an
awful lot like using a lookup field in the design of a table. It
masks the fact that an event is triggering some action. I favour
Call RunSomeCoolCode () in the Event's Sub in the form's code module.
There a sub is a sub and a function is a function.

[lauren quantrell]

Re: Function vs Sub /Public vs Private

I agree with you 100% except that in MS Access forms load much faster
when they have no code module, so in general I choose to use OnClick =
"=RunSomeCoolCo de()" and avoid having a form code module whenever
possible.