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:
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.
> 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:
> 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.
Well, you get a question on startup if you would like to try to load the packages at next startup. If you choose 'Yes' and restore the files, Delphi will try to load the packages at next start.
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...
> 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. -...
> 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.
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?
> 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.
Atmapuri wrote: > 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.
> 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".
> And Delphi seems to feel a bit faster too, though this may just be my > 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).
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).
"Kyle A. Miller" <kyle@millerdevelopment##remove#.info> wrote in message <41d1ef2...@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.
> 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.
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.
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
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.
> 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 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...
