Nah, it's interesting to see how the other half lives sometimes ;-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Sugrue Sent: Monday, 24 July 2006 11:39 a.m. To: [EMAIL PROTECTED]; '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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
