You make a good point. The difference really is miniscule and MAY only be
felt in a complex environment: many arguments, complex arguments such as
arrays and pointers, etc., resource-intensive processes running concurrently,
and so on. Even then, Id concede that youd be hard pressed to find a
difference in performance. But thats not really what its about. It goes
against best practices. Philosophically: Why call a procedure to call a
procedure? Whether the hit is felt in performance or not, it most definitely
is another layer of processing, and, as such, it is wasteful. Even if only
philosophically.

I've heard the argument for documentation, but here are some points about
that: There are better ways to document things than with a call that makes a
call to a call. You could use €˜^ for sub procedure calls and, lets say, €˜^^
for function calls:

MyProc €˜^
MyFunc() €˜^^

Either of which should stand out better than the word Call. Besides, what's
really the point of documenting a call? If there is a point, then why not
come up with any combination of symbols to represent other types of
statements? Why document just calls, after all? Why not also document
assignments, branches, etc.? We usually document processes; we don't usually
point out: "This is a call, this is a function, this is a branch." When we
document code, it is to point out what happens when, what the logic is behind
what we're doing, and so on. Besides, really, with practice you learn to spot
the sub procedure calls as easily as with a call to Call, or as easily as you
spot function calls. Or assignments, branches, etc.

In almost all cases, the Call statement makes no unique contribution. It
offers no added value and is philosophically bizarre. It is thus silly (no
offense meant to anyone). There is one case in which the Call statement makes
sense. And thats when you want to discard the return value of a function.

Call MyFunc()

will run the function as if it were a sub procedure and the return value
will be ignored. This is the only instance where Call actually has something
unique and justifiable to contribute.

I realize all this may seem very anal to a lot of people, but I do believe
that the philosophy you employ in your coding will end up reflecting in a lot
of places: Elegance (simplicity + functionality), efficiency, clarity,
consistency, etc., all of which ultimately add up to make better programs.

Peter :)



"Jim Cone" wrote:


I ran my own code using "timeGetTime" over 100,000 loops.
"Call" averaged 48 milliseconds.
Without "Call" averaged 48 milliseconds. (identical result)
Each version was run 20 times.

Also, Call is self documenting.
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware
(Excel Add-ins / Excel Programming)





"Jim Thomlinson"

wrote in message
I was not doubting you I was just curious. When I tested it I found no
appreciable difference so I was wondering if there was any kind of info on
it. I like knowing what the compiler is up to and what will generate more
efficient code...

Sub TimeTest()
Dim lng As Long
Dim dblStartTime As Double
Dim dblEndTime As Double
Const lngLoops As Long = 100000000

dblStartTime = Timer
For lng = 1 To lngLoops
Call DoStuff
Next lng
dblEndTime = Timer
MsgBox "Duration " & dblEndTime - dblStartTime

dblStartTime = Timer
For lng = 1 To lngLoops
DoStuff
Next lng
dblEndTime = Timer
MsgBox "Duration " & dblEndTime - dblStartTime

End Sub
Sub DoStuff()
Dim x As Long
x = 1
End Sub
--
HTH...
Jim Thomlinson