Update #1 and memory leaks!
Atmapuri
For those that still expirience memory leaks with
Update #1:
The severity of the memory leaks is proportional
to size of the source file being edited.
To completely resolve them:
Remove or rename the following packages
to disable Together:
"tgide90.bpl"
"borland.studio.together.dll"
in the \Bin directory.
It is not sufficient to disable Together from the Project
menu!!! The memory leaks due to Together will
happen as soon as you use the code editor and while
the Delphi is starting.
After you have disabled Together, you will notice, that
memory usage after D2005 has started is only half
of what it is otherwise. (85MB instead of 200 or so). The size
of the memory allocated by the process can be checked accurately with
this tool:
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
The Windows page file usage is not very accurate. But you get
a .NET and W32 side breakdown with that tool.
To get a .NET garbage collector breakdown use this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto13.asp
You will be able to see the culprit (Together) on the work.
With the original release of D2005 there were memory leaks in
the code editor itself also. Even without Together.
Those have been fixed with Update #1.
I also found the IDE much more stable and reporting more
usefull error message after disabling Together.
I hope some will find this usefull.
Best Regards!
Atmapuri.
Derek Davidson
> I hope some will find this usefull.
Great info. Thanks :-)
--
Derek Davidson
http://www.ebsms.com
Send SMS Text messages from your PC. For FREE!
Lars O. Soderstrom
Lars
"Atmapuri" <janez.m...@usa.net> skrev i meddelandet
news:41cf...@newsgroups.borland.com...
Dennis Landi
Do I need it for ECO II?
-d
Kevin Berry
> I hope some will find this usefull.
> Best Regards!
> Atmapuri.
OK, but what do you lose by disabling it? I use Delphi 2005
Professional. Does this affect me?
Thanks,
Kevin.
dk_sz
>> "borland.studio.together.dll"
>>
>> in the \Bin directory.
Will Delphi autoload it again if one renames/places "tgide90.bpl"
back? (e.g. when Borland fixes the memory leaks)
best regards
Thomas Schulz
Lars O. Soderstrom
packages at next startup. If you choose 'Yes' and restore the files, Delphi
will try to load the packages at next start.
Lars
"dk_sz" <dk...@hotmail.com> skrev i meddelandet
news:41d0...@newsgroups.borland.com...
Philip Hofstetter
Atmapuri wrote:
> To completely resolve them:
> Remove or rename the following packages
> to disable Together:
This seems to have fixed my problems with ErrorInsight as well.
Before disabling those packages, sometimes, ErrorInsight complained
about unknown types which definititely were not unknown at all (like
TObject for example). Needless to say that the units compiled without
errors too.
And Delphi seems to feel a bit faster too, though this may just be my
imagination...
Thanks anyway.
Philip
Atmapuri
> OK, but what do you lose by disabling it? I use Delphi 2005
> Professional. Does this affect me?
It affects ECO II modeling in Delphi.NET and C#. ECO II will still
work, but modeling will not. If you use W32 only
I think you dont loose anything.
But if Together is loaded the W32 side is for my purpose
not really usable. Without it its like breath of life for IDE.
A few things I noticed:
- big projects are loaded instantly.
- memory is no longer a problem, stays very low constantly
- I get compiler errors where there used to be AV's
or just nothing.
-...
Best Regards!
Atmapuri
Bryce K. Nielsen
> menu!!! The memory leaks due to Together will
> happen as soon as you use the code editor and while
> the Delphi is starting.
>
What's the "proper" way to disable Together then? Is it Tools | Together? Do
you have to do each Project? And finally also rename the DLLs?
-BKN
Holger Flick
it's great what you proposed. Everything is way faster now!! I never
used the Together support for my existing projects anyway.
--
Holger
Kyle A. Miller
> With the original release of D2005 there were memory leaks in
> the code editor itself also. Even without Together.
> Those have been fixed with Update #1.
>
> I also found the IDE much more stable and reporting more
> usefull error message after disabling Together.
Can someone from Borland or TeamB verify this? Hopefully a separate
Together patch could be released to fix this.
![Nick Hodges [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWsTjWTtYgQa_lIkPPY_9f1apuJLHGnOXqRfdvL-25iS-D7ruXW=s40-c)
Nick Hodges [TeamB]
> Can someone from Borland or TeamB verify this?
I did it and found memory use to be better.
--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick
Captain Jake
<41cf...@newsgroups.borland.com>
> The memory leaks due to Together will
> happen as soon as you use the code editor and while
> the Delphi is starting.
>
> After you have disabled Together, you will notice, that
> memory usage after D2005 has started is only half
> of what it is otherwise.
This is probably one of the best arguments against using Java or .NET or any
other garbage-collected framework, namely that people will interpret the
activities of the garbage-collector as a "memory leak".
--
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.362
Bryce K. Nielsen
> imagination...
>
I've found this to keep the memory leaks WAY down, but the Delphi IDE is
still incredibly slow. When I double-click on a TFrame in my ProjectManager,
about 5 to 8 seconds later does it finally load up in the editor. Going from
Form-to-Code takes upwards of 4 seconds too, and even more annoying, if I
have the Form open and then I click on the editor, the mouseup doesn't get
called until AFTER those 4 seconds are up, so if I move the mouse anywhere
after I click, a whole bunch of text is highlighted (which really sucks,
since I normally just click on the editor and start typing, but now I have
to wait and make sure that nothings highlighted or I lose a bunch of text).
Does your IDE respond faster?
-BKN
Nick Hodges [TeamB]
> namely that people will interpret the
> activities of the garbage-collector as a "memory leak".
In actuality, the garbage collector is really the problem, though it
/looks/ like a memory leak.
dk_sz
I have it around one second. Of course I did various other things as well.
(see borland.public.delphi.ide.general - around 23 dec.)
it's still slower than D6 though, but can now be tolerated (using P4 2,8
mhz).
best regards
Thomas Schulz
Nick Hodges [TeamB]
> Is this a case of a poor garbage collector or a real memory leak?
Well, that will be debated forever, I suppose. It's probably both, but
the garbage collector problem is probably the one causing most of the
problems.
Kyle A. Miller
> In actuality, the garbage collector is really the problem, though it
> /looks/ like a memory leak.
I thought we settled on it being a memory leak. Is this a case of a poor
Captain Jake
<41d1ef27$1...@newsgroups.borland.com>
> I thought we settled on it being a memory leak. Is this a case of a poor
> garbage collector or a real memory leak?
I guess if you really think about it, you'll conclude that it doesn't really
matter which it is, since the problem is not nomenclature, but an
ever-increasing memory consumption that brings lesser systems to their knees.
If this is the normal result of a garbage collector, or the result of a true
memory leak, it is the result that is the problem. I guess we had better hope
it is NOT the memory collector, since that can't be fixed as easily as a true
memory leak.
Atmapuri
> This is probably one of the best arguments against using Java or .NET or
any
> other garbage-collected framework, namely that people will interpret the
> activities of the garbage-collector as a "memory leak".
The keyword here is the "CLR Profiler" from Microsoft.
If you did not bother to read the manual here are a few points:
- you can track how long are objects alive.
- which objects
- how large
- and per property breakdown. (sub-objects)
- how many total allocations/deallocations per time
unit (to see if garbage collector is eating away CPU).
Garbage collector or memory leak is not a question at all.
You can check bds.exe yourself and determine exactly which
objects from which assembly are causing the problem to
what extent.
If you are writing "large" .NET apps, CLR Profiler is a
must.
I think that one of the reasons why there is still some myst
to what is real memory usage and what is leak, is
because there is still "magic" associated with the "garbage
collector". The CLR Profiler can do away all the fog.
Best Regards!
Atmapuri
C4D - Kim Madsen
Having a working garbage collector, traditional memory leaks dont occur anymore... ie people forget about a piece of
allocated memory and thus forgets to free it.
The garbage collector _do_ know about all the allocated memory, and keeps track of it.
The problem that mimics a leak is when something holds references to allocated memory. I.e. a list structure where each
element points to a managed objec that have been allocated somewhere.
Eg.
a:=someobject.Create;
somelist.add(a);
a:=nil;
Even if your original variable referencing the allocated object is cleared out or getting out of scope, there still is
a reference to the object in the list. As long there are references to the object, the garbage collector wont bin it.
This is a very simple example, but in something as complex as a compiler/parser keeping track of millions of objects and
with all the events getting triggered and triggering other events etc. it can be a very tough job detecting what
references are being left behind and what are being correctly cleared thus resulting in the release of memory.
Im personally not for gc setups... they have their merrits, but unfortunately it also means that it makes some people
think they are expert programmers while they are really not. Java and C# encourages to creation of huge amounts of
objects without the developer giving it any thought, which means that house keeping and ressource management is
completely disregarded by many in GC operated environments.
In the good old days, developers knew they had to take housekeeping and ressource management into account to avoid
disaster. Thus they did and thus those apps spend alot less ressources than the new generation.
Just my 5 øre (cents) :)
Happy new year!
--
best regards
Kim Madsen
k...@components4developers.com
www.components4developers.com
The best components for the best developers
kbmMW - RAD Enterprise class n-tier application server framework
kbmMemTable - High performance memory table
kbmWABD - RAD web development
kbmX10 - RAD house automation
"Kyle A. Miller" <kyle@millerdevelopment##remove#.info> skrev i en meddelelse news:41d1ef27$1...@newsgroups.borland.com...
JED
> To completely resolve them:
> Remove or rename the following packages
> to disable Together:
>
> "tgide90.bpl"
> "borland.studio.together.dll"
>
> in the \Bin directory.
Don't do this.
Use this: www.alphalink.com.au/~jed/dcm.htm
What if you actually want to use together for a particular project?
BTW, i have together loaded and no system performance drop. It really
depends on your projects and system - I'd recommend checking first
before disabling for no reason.
--
QC Client: http://www.alphalink.com.au/~jed/QC/
Blog: http://jedqc.blogspot.com/
Configure Delphi 2005 the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm
Checkout my code central submissions for D2005
http://cc.borland.com/ccweb.exe/author?authorid=205627
Holger Flick
> What if you actually want to use together for a particular project?
Rename them again. However, you are right. I would not know how to
include them into the IDE again.
But I checked out the Together support and could not find any reason
using it at all. May be because we were forced at University to model
using Rational Rose, I am still recovering from that :-)
--
Holger
Bryce K. Nielsen
> really
> matter which it is, since the problem is not nomenclature, but an
> ever-increasing memory consumption that brings lesser systems to their
> knees.
> If this is the normal result of a garbage collector, or the result of a
> true
> memory leak, it is the result that is the problem. I guess we had better
> hope
> it is NOT the memory collector, since that can't be fixed as easily as a
> true
> memory leak.
>
"Lesser machines"?!? I have a Centrino 1.7 w/1mb RAM and it had consumed
over 2 GIGABYTES of memory. That will bring down many "greater" machines...
-BKN
Bryce K. Nielsen
> (see borland.public.delphi.ide.general - around 23 dec.)
> it's still slower than D6 though, but can now be tolerated (using P4 2,8
> mhz).
>
Maybe I'm doing something wrong. I saw your posts on IDE, and mine still
crawls. I have free-floating IDE (thank goodness), disabled the Together in
the Tools|Options, and renamed Together DLLs. What else can I do to speed
this up, because it literally takes 4 to 5 seconds when I hit F12...
-BKN
Greg Eytcheson
> "Lesser machines"?!? I have a Centrino 1.7 w/1mb RAM and it had consumed
> over 2 GIGABYTES of memory. That will bring down many "greater"
> machines...
Thinking back, I don't recall seeing a single message about huge memory use
from a user that has less than 1GB RAM. Perhaps it is the machines with a
great deal of memory that are affected the most...
Greg
Robert Wachtel
> [...] I have a Centrino 1.7 w/1mb RAM [...]
Impressive... <eg>
scnr
Greetings from Cologne
Robert
Bryce K. Nielsen
> use from a user that has less than 1GB RAM. Perhaps it is the machines
> with a great deal of memory that are affected the most...
>
Hrm, now that's an interesting thought. If this memory usage is due to the
garbage collector, I wonder if in larger machines the GC decides to go for a
long time since it's got so much more memory...
-BKN
David Clegg
> If this memory usage is due to the
> garbage collector, I wonder if in larger machines the GC decides to
> go for a long time since it's got so much more memory...
Perhaps that logic was coded by a disgruntled MS developer who's boss
refuses to upgrade the 256Mb RAM in his development machine. :-)
--
Cheers,
David Clegg
dcl...@gmail.com
Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 :-)
Now supports Google Groups searching with Dyna-extend(tm) technology!
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"I don't have to be careful. I've got a gun!" - Homer Simpson
dk_sz
> this up, because it literally takes 4 to 5 seconds when I hit F12...
When I debug-stepped code it would take 3-4 seconds .. for each step.
I figured it was because Delphi has to update lots of visible windows each
time.
Docking them all together does only one is visible at a time (at least the
way
I have them docked). I am 99,99% sure I got a very real speed increase
there.
I think it's the same with F12.
My Delphi 2005 IS still visible! slower than Delphi6
(but I can use D2K5 without killing myself in agony now)
best regards
Thomas
Andrew
well, the trial does run OK on my 256mb machine... and I have been
watching the memory usage...
maybe with a tonne of RAM the GC gets bored and falls asleep...
Liz
> well, the trial does run OK on my 256mb machine... and I have been
> watching the memory usage...
Given I have 1gb and the trial was hogging my PC so bad it couldnt even
play my TV card which can keep going even if the PC crashes.. Id say it
can hog :)
Captain Jake
<41d2869e$1...@newsgroups.borland.com>
> Im personally not for gc setups... they have their merrits, but unfortunately it also means that it makes some people
> think they are expert programmers while they are really not. Java and C# encourages to creation of huge amounts of
> objects without the developer giving it any thought, which means that house keeping and ressource management is
> completely disregarded by many in GC operated environments.
I am in deep agreement with this statement. But it reminds me of something
someone else wrote about GC, namely that you can write your code to
efficiently manage memory resources even in the GC environment of .Net, you
just have to take the effort to explicitly do it. In other words, though the
masses blunder headlong down the cliff of mindless garbage collection, there
are ways to build a nice parachute and glide safely.
Eric Grange
> I also found the IDE much more stable and reporting more
> usefull error message after disabling Together.
Could it mean that the Together .Net code has some buffer
overrun issues which result in some memory corruption on
the Win32 side?
Eric
Atmapuri
> > I also found the IDE much more stable and reporting more
> > usefull error message after disabling Together.
>
> Could it mean that the Together .Net code has some buffer
> overrun issues which result in some memory corruption on
> the Win32 side?
There are many unreproducable bugs in D2005. I can only
guess, but I think that many come from bugs in
W32/.NET interop, which only show themselves if the
garbage collector executes at a critical moment.
The more often the gargabe collector executes, (because
of bigger memory use), the more bugs you get.
When the memory stays low and consequently
GC collections occur much more rarely, you also
get less bugs <g>
Regards!
Atmapuri
P.S.
Needless to say, those W32 interop bugs can raise
the cost of software development beyond any possible
gain delivered by GC.
dk_sz
Oh yeah, Error insight slows a lot as well.
(as Danny mentions in the .ide thread.)
best regards
Thomas
Arthur Hoornweg
> In actuality, the garbage collector is really the problem, though it
> /looks/ like a memory leak.
Er, if the IDE starts throwing endless exceptions and the
current editing work can no longer be saved, such as the
original poster described, then this is a fatal flaw.
If it looks like a crash, tastes like a crash and behaves
like a crash, it's a crash.
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
Nick Hodges [TeamB]
> Er, if the IDE starts throwing endless exceptions and the
> current editing work can no longer be saved, such as the
> original poster described, then this is a fatal flaw.
That's true.
> If it looks like a crash, tastes like a crash and behaves
> like a crash, it's a crash.
That's true, too, though I'm not sure what your point is.
Arthur Hoornweg
> It's probably both, but
> the garbage collector problem is probably the one causing most of the
> problems.
Wasn't the whole purpose of a garbage collector to help prevent
that the software developers forget to release memory?
Arthur Hoornweg
> Perhaps that logic was coded by a disgruntled MS developer who's boss
> refuses to upgrade the 256Mb RAM in his development machine. :-)
A garbage collector that is garbage would make
an interesting recursion...
Nick Hodges [TeamB]
> Wasn't the whole purpose of a garbage collector to help prevent
> that the software developers forget to release memory?
Well sure. ;-)
(I'm no fan of garbage collectors, and would prefer to do it all
myself, but oh well....)
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> Wasn't the whole purpose of a garbage collector to help prevent
> that the software developers forget to release memory?
Perhaps. But more important is that it avoids problems with accessing
memory through stale pointers, i.e. accessing memory that was freed.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"If you give a man a fish, he will eat for today. If you teach him to
fish, he'll understand why some people think golf is exciting." -- P.G.
Wodehouse
Derek Davidson
> I'm no fan of garbage collectors, and would prefer to do it all
> myself, but oh well....
Me either. But I can imagine a scenario whereby Microsoft, having
suffered the fallout due to buffer overrun errors, decided that
programmers were really to blame and clearly cannot be trusted with
setting up and freeing memory correctly and so devised GC in .NET.
Caution: The above is pure conjecture based on absolutely no facts
whatsoever. It's a cynical whimsy written for fun only :-)
--
Derek Davidson
http://www.ebsms.com
Send SMS Text messages from your PC. For FREE!
Andrew Rybenkov
> suffered the fallout
well, Fallout was great, and Fallout 2 was even greater, that can't be said about MS.
Actually if MS played Fallout instead releasing another OS version, we all would be much more happy.
--
Andrew Rybenkov.
Bryce K. Nielsen
> said about MS.
> Actually if MS played Fallout instead releasing another OS version, we all
> would be much more happy.
>
Heck, even FalloutTactics was fun, though I do miss the richness of the
Fallout RPGs. I still play them ever now and then, there's so much in those
games. Even if they used the same bloody engine to make Fallout3 I'd buy
it...
-BKN
Arthur Hoornweg
> That's true, too, though I'm not sure what your point is.
My point is, it's no good blaming the garbage collector because
that was designed precisely to avoid this scenario (processes
forgetting to release resources).
OTOH, one could argue that this problem proves that the
garbage collector concept doesn't fulfill its promises
in a real-world scenario. The problem mentioned in
this thread just shouldn't be *possible*!
Bryce K. Nielsen
> garbage collector concept doesn't fulfill its promises
> in a real-world scenario. The problem mentioned in
> this thread just shouldn't be *possible*!
>
"possible" is the wrong word to emphasize there, "shouldn't" is the
pertinant word here. We all know that in programming, things that
*shouldn't* be possible tend to come to pass...
-BKN
John Kaster (Borland)
> Remind me again, what the Together stuff is for?
The design surface and UML visualization for the IDE.
> Do I need it for ECO II?
yes.
--
John Kaster http://blogs.borland.com/johnk
Features and bugs: http://qc.borland.com
Get source: http://cc.borland.com
What's going on? http://calendar.borland.com
Robert Love
> Hi JED,
>
> > What if you actually want to use together for a particular project?
>
> Rename them again. However, you are right. I would not know how to
> include them into the IDE again.
>
> But I checked out the Together support and could not find any reason
> using it at all. May be because we were forced at University to model
> using Rational Rose, I am still recovering from that :-)
I use Together, because I use ECO. Even with the few quirks of the
designer, I am far more productive now using ECO that I was before
doing things by hand. ECO is very, very cool!!!
The only major draw back, is once my model got to a certain size, I had
to switch from my laptop (512M RAM) to my desktop (1G RAM) because of
too much memory swapping, and it prevented effective testing. I have
yet to max out my desktop. So my only complaint is on the memory
footprint. I don't see memory leaks like others have reported, just
large amounts of stable memory usage. Although, I don't like software
forcing hardware upgrades, I was happy to order an new laptop and Jan
18th can't come quick enough ;-)
--
Robert Love - rober...@gmail.com
My Blog: http://peakxml.com
SLC Utah Delphi Users Group: http://www.slcdug.org
Place your Delphi Blog Here (For Free!): http://blogs.slcdug.org
Tony Caduto
I had D2005 architect just blink out of existence after multiple Out Of
Memory exceptions from the IDE.
Bryce K. Nielsen wrote:
>>I guess if you really think about it, you'll conclude that it doesn't
>>really
>>matter which it is, since the problem is not nomenclature, but an
>>ever-increasing memory consumption that brings lesser systems to their
>>knees.
>>If this is the normal result of a garbage collector, or the result of a
>>true
>>memory leak, it is the result that is the problem. I guess we had better
>>hope
>>it is NOT the memory collector, since that can't be fixed as easily as a
>>true
>>memory leak.
>>
>
>
> "Lesser machines"?!? I have a Centrino 1.7 w/1mb RAM and it had consumed
> over 2 GIGABYTES of memory. That will bring down many "greater" machines...
>
> -BKN
>
>
dk_sz
I tryed... But couldn't use with Jedi, my stuff, etc.
No way ?to select Delphi to load those BPLs as well.
best regards
Thomas
Liz
> > Use this: www.alphalink.com.au/~jed/dcm.htm
>
> I tryed... But couldn't use with Jedi, my stuff, etc.
> No way ?to select Delphi to load those BPLs as well.
Why not? works for me, and I use jedi as well as bunches of my own.
the bpls can be changed in your default project :)
Bryce K. Nielsen
>had D2005 architect just blink out of existence after multiple Out Of
>Memory exceptions from the IDE.
>
I've recently gotten this too, where in my application if I _compile_,
towards the end of the build (I think right before the linking occurs), all
of D2005 just "blinks out of existence". The whole application, poof, just
gone, no errors, no AVs, just gone. However, if I do a _build all_ instead
of a compile, it works fine. Really strange...
-BKN
Alisdair Meredith [TeamB]
> Im personally not for gc setups... they have their merrits, but
> unfortunately it also means that it makes some people think they are
> expert programmers while they are really not. Java and C# encourages
> to creation of huge amounts of objects without the developer giving
> it any thought, which means that house keeping and ressource
> management is completely disregarded by many in GC operated
> environments.
>
> In the good old days, developers knew they had to take housekeeping
> and ressource management into account to avoid disaster. Thus they
> did and thus those apps spend alot less ressources than the new
> generation.
I believe this is the major selling feature that launched garbage
collectors to Enterprise Managers - you can trust your development to
staff who are not so specialised-developers. Rather than spending time
worrying about cleaning up after all those resource allocations, they
can worry about the real business problems instead.
To an extent, this means you can introduce really smart people, strong
in the business domain who need less training in the IT skills. It
also means you have fewer risks with sweatshops full of 'VB-monkeys'
(an unfair term, but you know the kind of developer we are talking
about ;?)
The fact is GC does not free you from resource management concerns, but
the way you deal with them changes. In the old-school, you went into
painstaking detail through you code matching de-allcation to allocation
through all possible code-paths. Now, you mainly worry about creating
too many temporary objects, so switch to a different pattern that
creates fewer temps when you spot the problem - *usually* the problem
is not isolated to just the point-of-creation.
AlisdairM(TeamB)
Bryce K. Nielsen
> the way you deal with them changes. In the old-school, you went into
> painstaking detail through you code matching de-allcation to allocation
> through all possible code-paths. Now, you mainly worry about creating
> too many temporary objects, so switch to a different pattern that
> creates fewer temps when you spot the problem - *usually* the problem
> is not isolated to just the point-of-creation.
>
And this is what I fear when I hear point-haired-managers saying things like
"moving to .NET will fix all our memory problems". IMHO, if you have memory
problems, the fault is not the memory manager, it's typically the coders not
knowing how to properly handle memory. Moving to a GC environment will NOT
fix that problem, since again, these coders will not know the proper way to
manage said memory...
-BKN
Liz
> And this is what I fear when I hear point-haired-managers saying
> things like "moving to .NET will fix all our memory problems". IMHO,
Problem is irrelevant of any issues, the pointy haired boss will say
"no, we're going .net it is the only way" and you well just have to sit
there and chew your pencils with frustration.
Jack Johnson
<SNIP>
> Use this: www.alphalink.com.au/~jed/dcm.htm
>
> What if you actually want to use together for a particular project?
>
> depends on your projects and system - I'd recommend checking first
> before disabling for no reason.
The Delphi Configuration Manager is a great tool - thanks much! I'm
wondering if I'm missing something - when I start D2005 with the Launcher,
it doesn't load GExperts or Castalia, and I don't see those packages listed
to check or clear. Am I overlooking something, or is that not possible as of
version 1.5?
--
Jack Johnson
Cyberworlds Inc.
http://www.cyberworlds.com/
http://www.swidgets.com/
608-362-0318 x114
JED
> JED wrote:
> <SNIP>
> > Use this: www.alphalink.com.au/~jed/dcm.htm
> >
> > What if you actually want to use together for a particular project?
> >
> > BTW, i have together loaded and no system performance drop. It
> > really depends on your projects and system - I'd recommend checking
> > first before disabling for no reason.
>
> The Delphi Configuration Manager is a great tool - thanks much! I'm
> wondering if I'm missing something - when I start D2005 with the
> Launcher, it doesn't load GExperts or Castalia, and I don't see those
> packages listed to check or clear. Am I overlooking something, or is
> that not possible as of version 1.5?
It is not possible as of Version 1.5 - it will be when 2.0 is released.
I am hoping to release a 1.6 version tonight - that address a bug and a
couple of new gui features, plus an IDE addin.
--
QC Client: http://www.alphalink.com.au/~jed/QC/
Blog: http://jedqc.blogspot.com/
Configure Delphi the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm
Checkout my code central submissions for D2005
http://cc.borland.com/ccweb.exe/author?authorid=205627
Jack Johnson
<SNIP>
> It is not possible as of Version 1.5 - it will be when 2.0 is
> released. I am hoping to release a 1.6 version tonight - that address
> a bug and a couple of new gui features, plus an IDE addin.
OK - thanks!
Jack Johnson
> Hi JED,
>
>
> include them into the IDE again.
>
> But I checked out the Together support and could not find any reason
> using it at all. May be because we were forced at University to model
> using Rational Rose, I am still recovering from that :-)
In case anybody is still wondering about how to re-enable these packages in
the IDE, here's what I found on my system:
After renaming tgide90.bpl & borland.studio.together.dll, I responded to
D9's startup prompts by telling it to disable tgide90.bpl,
borland.studio.together.dll, & borland.together.ecodiagram.dll. D9
accomplished this by the following registry entries, all under
HKCU\software\borland\bds\3.0:
Added: Disabled IDE Packages -> c:\program
files\borland\bds\3.0\bin\tgide.bpl
Modified: Known IDE Assemblies -> $(BDS)\Bin\Borland.Studio.Together.dll
(data string='')
->
$(BDS)\bin\Borland.Together.EcoDiagram.dll (data string='')
Deleting the value c:\program files\borland\bds\3.0\bin\tgide.bpl from
Disabled IDE Packages, and editing the values
$(BDS)\Bin\Borland.Studio.Together.dll &
$(BDS)\bin\Borland.Together.EcoDiagram.dll to have any arbitrary text data
caused D9 to prompt for their inclusion again at the next launch.
Andrew Rybenkov
--
Andrew Rybenkov.
Alisdair Meredith [TeamB]
> Im personally not for gc setups... they have their merrits, but
> unfortunately it also means that it makes some people think they are
> expert programmers while they are really not. Java and C# encourages
> to creation of huge amounts of objects without the developer giving
> it any thought, which means that house keeping and ressource
> management is completely disregarded by many in GC operated
> environments.
>
> In the good old days, developers knew they had to take housekeeping
> and ressource management into account to avoid disaster. Thus they
> did and thus those apps spend alot less ressources than the new
> generation.
I believe this is the major selling feature that launched garbage
collectors to Enterprise Managers - you can trust your development to
staff who are not so specialised-developers. Rather than spending time
worrying about cleaning up after all those resource allocations, they
can worry about the real business problems instead.
To an extent, this means you can introduce really smart people, strong
in the business domain who need less training in the IT skills. It
also means you have fewer risks with sweatshops full of 'VB-monkeys'
(an unfair term, but you know the kind of developer we are talking
about ;?)
The fact is GC does not free you from resource management concerns, but
the way you deal with them changes. In the old-school, you went into
painstaking detail through you code matching de-allcation to allocation
through all possible code-paths. Now, you mainly worry about creating
too many temporary objects, so switch to a different pattern that
creates fewer temps when you spot the problem - *usually* the problem
is not isolated to just the point-of-creation.
AlisdairM(TeamB)
Ingvar Nilsen
> I believe this is the major selling feature that launched garbage
> collectors to Enterprise Managers - you can trust your development to
> staff who are not so specialised-developers.
This is not the way I see it.
To me, it has nothing to do with being more skilled to know how get rid
of garbage. If you can create an object, you can also get rid of it. And
if being skilled is to remember to do things, those forgetting to free
up resources will not be useful in any case, they will forget about
other important things instead.
No, to me garbage collecting is taking care of tedious routine work,
making me concentrate better on the main purpose of an object.
If the framework allows objects already out of scope float around
purposelessly, then it has to be improved, garbage collecting still
isn't bad because of that, the framework just needs to be improved, or
maybe tuned better.
Delphi already has GC, I use interfaces all the time, and they are freed
up as soon as getting out of scope, although I myself sometimes do it
deliberately, but not often.
> To an extent, this means you can introduce really smart people,
> strong in the business domain who need less training in the IT
> skills. It also means you have fewer risks with sweatshops full of
> 'VB-monkeys' (an unfair term, but you know the kind of developer we
> are talking about ;?)
I think you have misunderstood the purpose of GC somewhat :)
--
Ingvar Nilsen
Atmapuri
> No, to me garbage collecting is taking care of tedious routine work,
> making me concentrate better on the main purpose of an object.
> If the framework allows objects already out of scope float around
> purposelessly, then it has to be improved, garbage collecting still
> isn't bad because of that, the framework just needs to be improved, or
> maybe tuned better.
The most simple "leaks" are the ones of the programmer. You can
not allocate the memory and forget to free it with GC, but you can still
allocate too much. (hold references to unused objects for too long). How?
SetLength(ArrayOfObjects,SomeLength);
As long as at least one element of the array is still referenced in code
the objects at other indexes will also not be freed.
One has to admit though, that this can happen without GC also.
(next to a bunch of other memory leak types).
Regards!
Atmapuri.
Ingvar Nilsen
> Hi!
Hi! :)
> SetLength(ArrayOfObjects,SomeLength);
>
> As long as at least one element of the array is still referenced in
> code the objects at other indexes will also not be freed.
What when ArrayOfObjects get out of scope?
--
Ingvar Nilsen
Atmapuri
> > SetLength(ArrayOfObjects,SomeLength);
> >
> > As long as at least one element of the array is still referenced in
> > code the objects at other indexes will also not be freed.
>
> What when ArrayOfObjects get out of scope?
Then all are freed. But I was talking about referencing this:
ArrayOfObjects[i]
The GC can not predict which indexes are going or not going
to be used. It may even depend on the user input. The
"memory leaks" in .NET are just objects which
are not used anymore, but can not be freed either because
of the structure in which they are stored and because
their lifetime can not be determined by the GC automatically
(not even in theory).
So, GC is great and works fine, but you are not allowed to
become completely sloppy <g>.
But it may even be that without GC you would be getting AV
or other errors that would point out the problem. With GC
everything is automatic and can hide some of the problems
that previously could not be hidden.
Regards!
Atmapuri
Corbin Dunn
This test case was too simple.
A .NET memory "leak" can occur when you place something in a rooted list
(or in any rooted object) and forget to remove it from that list, even
after the object is no longer needed. This can be particularly bad if
that object has many other objects it points too.
-corbin