Returning function name value vs dim value

[Tom C]

Just wondering, aside from readibility, is there any cost or benefit
to using the function declaration value as opposed to a dim value to
return the value of a function. It seems to be the 2nd perhaps
preferred method creates yet another object that has to be managed?

function x as object
x = something
end function

or

function x as object
dim o as object = something
return o
end function

 

[Miro]

I would say that the second meathod you mentioned is the proper way.

funciton bla() as object
dim o as object = something
return o
end function

The only time I have seen the other being used is in old "Microsoft Access
Code" where the function name is actually the object.
To me, a function is a function, a sub is a sub, and a variable that
contains an object is a variable that contains an object.

I personally try to keep them seperate.



Miro

 

[Tom C]

I would say that the second meathod you mentioned is the proper way.

funciton bla() as object
dim o as object = something
return o
end function

The only time I have seen the other being used is in old "Microsoft Access
Code" where the function name is actually the object.
To me, a function is a function, a sub is a sub, and a variable that
contains an object is a variable that contains an object.

I personally try to keep them seperate.

Miro







- Show quoted text -

I am looking more for more memory impact and load than coding styles.
It is probably more readable the 2nd way but in a very large app, does
it have any impact on application. Does it create more gchandles,
cause more collection, etc...

 

[Tom Dacon]

I am looking more for more memory impact and load than coding styles.
It is probably more readable the 2nd way but in a very large app, does
it have any impact on application. Does it create more gchandles,
cause more collection, etc...

Tom, eighty percent of the so-called optimization that programmers worry
about makes no perceptible difference in the performance of an application,
and this is a sterling example. If you want to make a difference, work on
your algorithms, not tiny code-generation issues like this.

Tom Dacon
Dacon Software Consulting

 

[David Anton]

The first way is a terrible VB holdover from long ago - if anyone not very
familiar with VB has to maintain your code then they'll be scratching their
head over this VB-unique way of setting a value to return from a function.

You are also not saving any object creations using the legacy VB approach -
a hidden variable is created behind the scenes which VB causes the function
to return when it hits either an 'Exit Function' or 'End Function'.

 

[Tom C]

I really don't believe any optimization to be trivial when my app
quickly grows to 500,000 to 1 million gchandles within a short period
of running. Now we have workarounds to handle it and release for
instance the __enclist which is created by a debug build. Maybe you
have the luxury of giving customers a release build and don't have to
deal with this but until I can skip the __enclist and still get line
numbers in exception, i can't. So if I can avoid duplicate gchandles
just because I use the existing variable, then programmers can learn
to read it; if not, I suggest a less taxing occupation. lol

 

[Family Tree Mike]

Just wondering, aside from readibility, is there any cost or benefit
to using the function declaration value as opposed to a dim value to
return the value of a function. It seems to be the 2nd perhaps
preferred method creates yet another object that has to be managed?

function x as object
x = something
end function

or

function x as object
dim o as object = something
return o
end function

You should look at the IL to see if there is any difference between the
methods.

Running the following three versions through loops 100,000,000 times
each, shows method three is consistently faster. You need to perform
more representative tests with your functions though.

Function x1() As Object
x1 = New Object
End Function
Function x2() As Object
Dim s As Object = New Object
Return s
End Function
Function x3() As Object
Return New Object
End Function

 

[Alex Clark]

Tom,

I believe David answered your question accurately and politely, without
making any accusations or degrading comments about you or your code. Do you
think it might be nicer to respond in kind, rather than be so defensive?

I would be curious as to what it is you're doing that allocates quite so
many GC Handles in a short period? I would suggest that if you're at the
level of optimising by trying to save individual object references, then the
problem is likely with your design rather than on an individual line-by-line
declaration basis. This is not to say that there is a better alternative to
your design - your spec and requirements may be unusual enough to
necessitate such a pattern - but I am interested to know what you're doing
to flood the heap like that. Maybe someone can offer you some more help?

Kind Regards,
Alex

 

[Göran Andersson]

The first way is a terrible VB holdover from long ago - if anyone not very
familiar with VB has to maintain your code then they'll be scratching their
head over this VB-unique way of setting a value to return from a function.

Well, it's not really unique to VB, Pascal also had this way of
assigning the return value to the function name. About 20 years ago the
Return command was added to the (Turbo) Pascal language, it's about time
to start using it in VB also...

 

[Göran Andersson]

Just wondering, aside from readibility, is there any cost or benefit
to using the function declaration value as opposed to a dim value to
return the value of a function. It seems to be the 2nd perhaps
preferred method creates yet another object that has to be managed?

function x as object
x = something
end function

or

function x as object
dim o as object = something
return o
end function

What happens exactly is this:

When the method is called, space is allocated on the stack for the extra
variable. This uses four bytes of stack space (eight in an x64 app), but
the cost in execution time is zero as the stack frame is always created
anyway.

Then the variable is initialised to the default value (null/zero). This
is one or two machine code instructions, with a cost anywhere between
zero and almost nothing.

When the method exits the stack frame is removed by simply restoring the
stack pointer, so there is no extra cost in removing the variable.

There is no extra references created. There is no extra gchandles
allocated. There is no heap space allocated. There is no extra garbage
collection that has to be done.

Besides, sometimes the JIT compiler can even remove local variables that
are not really needed. In your example it's quite likely that this will
happen.

So, declaring local variables is very very cheap, and if it improves the
code in any way, you should not hesitate to use some local variables.