[DUG] Related try..finally question

[Leigh Wanstead]

Hi James,

I don't know C#/.NET. I just copy Paul's code and make some change to fit
the logic I want to explain. My understanding is C# just like java which is
different from native compiler language i.e. delphi. In delphi I can
precisely see/control what is going on in assembler level if I wish, but not
C#/.NET. I will be completely lost if I post the discussion in .net mailing
list.

Regards
Leigh

-----Original Message-----
From: James Sugrue [mailto:jamessugrue at xtra.co.nz]
Sent: Monday, 24 July 2006 11:39 a.m.
To: leighw at softtech.co.nz; 'NZ Borland Developers Group - Delphi List'
Subject: RE: [DUG] Related try..finally question


You're effectively doing what the using statement caters for.

Also, I'm pretty sure that the GC is doing behind the scenes what you are
doing in code. It is smart enough to reuse memory allocated to an object if
that object goes out of scope and is then reused - if not in .NET 2.0 then
definitely in the release that LINQ comes in.

You say your way improves time and performance. Are you programming for a
Commodore 64? I wouldn't have though on modern machines it would be an
issue?

BTW this discussion might be better on the .NET list, rather than bore DUG
with C#/.NET issues....

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Leigh Wanstead
Sent: Monday, 24 July 2006 11:16 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Related try..finally question

new always involve memory allocation which cost time.

Here is what I think might help to improve performance

original code

a = new blah
try
{
   a.stuff
   a.stuff
   a.stuff
}
 finally
{
   a.dispose;
}

b = new blah
try
{
   b.stuff
   b.stuff
}
 finally
{
   b.dispose;
}

------------

Modified code
a = new blah
try
{
   a.stuff
   a.stuff
   a.stuff

   a.recycle

   a.stuff
   a.stuff
}
 finally
{
   a.dispose;
}

-------------
Or more clean code

a = ResourceEngine.getInstance(TYPE_A);
try
{
   a.stuff
   a.stuff
   a.stuff

}
 finally
{
   ResourceEngine.releaseResource(a);
}

b = ResourceEngine.getInstance(TYPE_A);
try
{
   b.stuff
   b.stuff
}
 finally
{
   ResourceEngine.releaseResource(b);
}

ResourceEngine is maintained by application programmer, not os. Application
has more knowledge than os about how to reuse the data thus result more
performance. But nowdays communication cost seems more dear than computation
cost, so it might not be so important anymore.

Regards
Leigh
www.smootharm.com

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz
[mailto:delphi-bounces at ns3.123.co.nz]On Behalf Of Paul Heinz
Sent: Friday, 21 July 2006 4:18 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Related try..finally question


Leigh wrote:

> I have done some coding and found that current issues for most programming
> is resource management i.e. memory allocation, TCP/IP connection
> allocation.
> If an application can manage resource well, the application will run very
> good. I am very relucant to give up this control to someone else to manage
> it. Delphi 7 gives me reasonable control over this sorts of issue. ;-)

I assume this is in reference to 'using' and .NET references implying
garbage collection.

Firstly, 'using' as a C# language semantic is distinct from garbage
collection.

using (a = new blah)
{
   a.stuff
   a.stuff
   a.stuff
}

is purely syntactic sugar and equivalent to:

a = new blah
try
{
   a.stuff
   a.stuff
   a.stuff
}
 finally
{
   a.dispose;
}

Manual (i.e. Delphi style) memory management (which is what garbage
collection resolves - other resources must still be managed as usual) is
overrated in my opinion. A well designed precise generational garbage
collector does just as good a job overall of managing memory as a developer
manually coding it, likely better if your object lifetimes and
interrelationships are complicated and your developer didn't miss anything.

In fact, in anything like the SQL parser, optimiser, and execution engine we
built, you end up spending a goodly chunk of your engineering and debugging
time writing fiddly lifetime management code i.e. a domain specific mini-
garbage collector anyway.

TTFN,
  Paul.



_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi


_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi