Prev: vb.net/networking....Turn on print Auditing for all Printers on print server using vb.net or VBS?????
Next: Record a Macro in VB.NET 2008 Express?
From: Tom C on 16 Dec 2009 18:01
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
From: Family Tree Mike on 16 Dec 2009 20:36
On 12/16/2009 3:19 PM, Tom C wrote:
> 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


--
Mike
From: Alex Clark on 16 Dec 2009 21:34
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



"Tom C" <tom_claffy(a)asdsoftware.com> wrote in message
news:4e3bf3de-1581-49ca-8ceb-7e1e60242aaf(a)s20g2000yqd.googlegroups.com...
>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


From: Göran Andersson on 17 Dec 2009 03:20
David Anton wrote:
> 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
_____
http://www.guffa.com
From: Göran Andersson on 17 Dec 2009 03:37
Tom C wrote:
> 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.

--
G�ran Andersson
_____
http://www.guffa.com
First  |  Prev  | 
Pages: 1 2
Prev: vb.net/networking....Turn on print Auditing for all Printers on print server using vb.net or VBS?????
Next: Record a Macro in VB.NET 2008 Express?