Hi,

Delphi XE7 IDE rapidly consume memory when loading and compiling my project several times.

64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.

Thanks
Tugrul

Tugrul Tamturk wrote:

> Delphi XE7 IDE rapidly consume memory when loading and compiling my
> project several times.
> 
> 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.

IMHO it would be better to fix memory leaks which gobble memory...

--
Alex

"Alex Belo" <b.a.v@inbox.ru> wrote in message 
news:725618@forums.embarcadero.com...
> Tugrul Tamturk wrote:
>
>> Delphi XE7 IDE rapidly consume memory when loading and compiling my
>> project several times.
>>
>> 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
>
> IMHO it would be better to fix memory leaks which gobble memory...
>

?

Is the source of the IDE available somewhere so that can be done by others 
than EMBT?

Or have I misunderstood one/both of you?

On 04/06/2015 8:07 AM, Tugrul Tamturk wrote:
> Hi,
>
> Delphi XE7 IDE rapidly consume memory when loading and compiling my project several times.
>
> 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
>
> Thanks
> Tugrul
>
For this reason, I am stuck on XE2 and won't (can't) upgrade until it 
gets fixed (apparently XE8 still has the problem).

 From what I have read elsewhere, EMB thinks that the solution is a 64 
bit IDE, and denies that there are any significant "memory leak" errors. 
If there are no memory leaks, then it seems to me that they have a 
design problem. Repeatedly compiling the same project should not cause 
memory consumption to increase over time, it just shouldn't. (If memory 
gets fragmented, then defragment it!)

More info here:

http://support.embarcadero.com/article/44279


J.

On 04/06/2015 8:07 AM, Tugrul Tamturk wrote:
> Hi,
>
> Delphi XE7 IDE rapidly consume memory when loading and compiling my project several times.
>
> 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
>
> Thanks
> Tugrul
>
For this reason, I am stuck on XE2 and won't (can't) upgrade until it 
gets fixed (apparently XE8 still has the problem).

 From what I have read elsewhere, EMB thinks that the solution is a 64 
bit IDE, and denies that there are any significant "memory leak" errors. 
If there are no memory leaks, then it seems to me that they have a 
design problem. Repeatedly compiling the same project should not cause 
memory consumption to increase over time, it just shouldn't. (If memory 
gets fragmented, then defragment it!)

More info here:

http://support.embarcadero.com/article/44279


J.

> IMHO it would be better to fix memory leaks which gobble memory...

Guess they could do both... while reviewing code to port it to 64 bit, spend the time to identify and remove leaks.

Today there are very little reasons to run a 32 bit OS but on RAM constrained machines - but maybe it's not the reason there's not yet a 64 bit IDE...

> {quote:title=Tugrul Tamturk wrote:}{quote}
> Hi,
> 
> Delphi XE7 IDE rapidly consume memory when loading and compiling my project several times.
> 
> 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
> 
> Thanks
> Tugrul

And while they're at it, remove any trace of   DotNet.  I know the Together and Refactoring stuff may be in DotNet, but they need to get rid of it/

Phillip Woon wrote:

> And while they're at it, remove any trace of   DotNet.  I know the
> Together and Refactoring stuff may be in DotNet, but they need to get
> rid of it/

Why?

-- 
Nick
Delphi Programming is Fun

> {quote:title=Nick Hodges wrote:}{quote}
> Phillip Woon wrote:
> 
> > And while they're at it, remove any trace of   DotNet.  I know the
> > Together and Refactoring stuff may be in DotNet, but they need to get
> > rid of it/
> 
> Why?
> 
> -- 
> Nick
> Delphi Programming is Fun

To make more profit on the intellectual property they own, and "companies exist to make profit"  ?

> {quote:title=Alex Belo wrote:}{quote}
> Tugrul Tamturk wrote:
> 
> > Delphi XE7 IDE rapidly consume memory when loading and compiling my
> > project several times.
> > 
> > 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
> 
> IMHO it would be better to fix memory leaks which gobble memory...
> 
> --
> Alex

My project group has several big projects. So There will be boundries even no memory leak. I understand IDE and compiler needs more memory paralel to software technology evolution. That's why I need to use more memory available in my computer for compiler (16 GB)..

I will have more continuous, fluent work process.

I am close open Delphi often during day unfortunately.

Regards
Tugrul

P Tytgat wrote:

> > {quote:title=Nick Hodges wrote:}{quote}
> > Phillip Woon wrote:
> > 
> > > And while they're at it, remove any trace of   DotNet.  I know the
> > > Together and Refactoring stuff may be in DotNet, but they need to
> > > get rid of it/
> > 
> > Why?
> > 
> > -- 
> > Nick
> > Delphi Programming is Fun
> 
> To make more profit on the intellectual property they own, and
> "companies exist to make profit"  ?

How does rewriting stuff that already works translate into more profit?

I'm not necessarily defending every single use of .Net in the IDE, but
if Embarcadero is going to spend time and resources rewriting things
instead of adding new features/functionality or fixing higher priority
bugs, there should be a really good reason.

Plus there's at least one part of the .Net framework that I like in Rad
Studio - MSBuild integration.

-- 
Regards,
Bruce McGee
Glooscap Software

P Tytgat wrote:

> 
> To make more profit on the intellectual property they own, and
> "companies exist to make profit"  ?

Huh?

-- 
Nick
Delphi Programming is Fun

Bruce McGee wrote:

> 
> Plus there's at least one part of the .Net framework that I like in
> Rad Studio - MSBuild integration.

Yeah, this is really great.

-- 
Nick
Delphi Programming is Fun

> {quote:title=John Furlong wrote:}{quote}
> On 04/06/2015 8:07 AM, Tugrul Tamturk wrote:
> > Hi,
> >
> > Delphi XE7 IDE rapidly consume memory when loading and compiling my project several times.
> >
> > 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
> >
> > Thanks
> > Tugrul
> >
> For this reason, I am stuck on XE2 and won't (can't) upgrade until it 
> gets fixed (apparently XE8 still has the problem).
> 
>  From what I have read elsewhere, EMB thinks that the solution is a 64 
> bit IDE, and denies that there are any significant "memory leak" errors. 
> If there are no memory leaks, then it seems to me that they have a 
> design problem. Repeatedly compiling the same project should not cause 
> memory consumption to increase over time, it just shouldn't. (If memory 
> gets fragmented, then defragment it!)
> 
> More info here:
> 
> http://support.embarcadero.com/article/44279
> 
> 
> J.

Today I disabled ERROR INSIGHT feature in DelphiXE7 Options.

Memory consumption reduced to half.

Delphi XE7 is more stable now....

Thanks.

> {quote:title=Nick Hodges wrote:}{quote}
> P Tytgat wrote:
> 
> > 
> > To make more profit on the intellectual property they own, and
> > "companies exist to make profit"  ?
> 
> Huh?
> 
> -- 
> Nick
> Delphi Programming is Fun

Hi Nick,

Main problem seems like ERROR INSIGHT feature...

Today I disabled ERROR INSIGHT feature in DelphiXE7 Options.

Memory consumption reduced to half.

Delphi XE7 is more stable now....

Thanks.

Tugrul Tamturk wrote:

> Main problem seems like ERROR INSIGHT feature...
> 
> Today I disabled ERROR INSIGHT feature in DelphiXE7 Options.
> 
> Memory consumption reduced to half.
> 
> Delphi XE7 is more stable now....

Yup, Embarcadero should absolutely fix error insight. It's been broken,
or at least unreliable, for a very long time.

It's a much more specific, and therefore actionable comment than
removing any trace of .Net from the IDE.

-- 
Regards,
Bruce McGee
Glooscap Software

david hoke wrote:

> Is the source of the IDE available somewhere so that can be done by
> others than EMBT?

:-)

I mean "EMBT should fix memory leaks in IDE".

Crashing IDE on low memory condition after some periodical actions
(like compilation) clearly indicates memory leaks in IDE.

Update: according to the support page they have memory fragmentation and
memory consuming features (Code Completion, Error Insight, and DCU
cashing).

In this case 64 bit will definitely help.

But I think that 32 bit still has reserves: why not use memory mapped
files, for example, to cash such big data?

--
Alex

Bruce McGee wrote:

> 
> It's a much more specific, and therefore actionable comment than
> removing any trace of .Net from the IDE.

And has nothing to do with .Net...... 

-- 
Nick
Delphi Programming is Fun

Nick Hodges wrote:

> Bruce McGee wrote:
> 
> > 
> > It's a much more specific, and therefore actionable comment than
> > removing any trace of .Net from the IDE.
> 
> And has nothing to do with .Net...... 

From what little I know about the problems with error insight, I think
you are correct.

I doubt that fixing the wrong things will help anyone make more profit.

-- 
Regards,
Bruce McGee
Glooscap Software

Am 04.06.2015 um 19:53 schrieb Nick Hodges:
> Phillip Woon wrote:
> 
>> And while they're at it, remove any trace of   DotNet.  I know the
>> Together and Refactoring stuff may be in DotNet, but they need to get
>> rid of it/
> 
> Why?
> 

If they still rely on J# to get rid of a 3rd party technology no longer
actively supported by that 3rd party for instance and to get rid of 3rd
party dependencies in general.

And in some cases that could be a welcome cause for revisiting some
areas like audits which have had quite a few issues because they were
originally written by folks not considering Delphi and its specifics and
then being ported by folks either not knowing those specifics or not
careing.

One example: it sometimes had issues with controls on forms as they were
in no visibility category (private...).

Greetings

Markus

I also would like to see this J# and .NET stuff removed from the IDE.
It just fills my SSD with un-needed stuff. And while D7 just install and works fine on linux/wine, I never got a new version of delphi XEn to work again on that platform. 


> {quote:title=Nick Hodges wrote:}{quote}
> Bruce McGee wrote:
> 
> > 
> > Plus there's at least one part of the .Net framework that I like in
> > Rad Studio - MSBuild integration.
> 
> Yeah, this is really great.
> 
> -- 
> Nick
> Delphi Programming is Fun

Tugrul Tamturk wrote:
>> {quote:title=Nick Hodges wrote:}{quote}
>> P Tytgat wrote:
>>
>>> To make more profit on the intellectual property they own, and
>>> "companies exist to make profit"  ?
>> Huh?
>>
>> -- 
>> Nick
>> Delphi Programming is Fun
> 
> Hi Nick,
> 
> Main problem seems like ERROR INSIGHT feature...
> 
> Today I disabled ERROR INSIGHT feature in DelphiXE7 Options.
> 
> Memory consumption reduced to half.
> 
> Delphi XE7 is more stable now....
> 
> Thanks.

Error Insight caches the information for later use.  This is why it uses more 
memory on larger projects.  So does Code Insight.  During compiles there is dcu 
caching going on.  Actually the IDE has very few minor leaks, what people calls 
leaks are actually misunderstanding that there is caching going on and 
intentional for performance reasons.

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted  corridors of Whitehall.
              (Fish)

Alex Belo wrote:
> david hoke wrote:
> 
>> Is the source of the IDE available somewhere so that can be done by
>> others than EMBT?
> 
> :-)
> 
> I mean "EMBT should fix memory leaks in IDE".
> 

You are confusing the IDE caching information with memory leaks. A rising memory 
footprint <> memory leak.

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted  corridors of Whitehall.
              (Fish)

Jeff Overcash (TeamB) wrote:

> A rising memory 
> footprint <> memory leak.

True that.

-- 
Nick
Delphi Programming is Fun

Am 05.06.2015 um 19:39 schrieb Jeff Overcash (TeamB):
> Tugrul Tamturk wrote:
>>> {quote:title=Nick Hodges wrote:}{quote}
>>> P Tytgat wrote:
>>>
>>>> To make more profit on the intellectual property they own, and
>>>> "companies exist to make profit"  ?
>>> Huh?
>>>
>>> -- 
>>> Nick
>>> Delphi Programming is Fun
>>
>> Hi Nick,
>>
>> Main problem seems like ERROR INSIGHT feature...
>>
>> Today I disabled ERROR INSIGHT feature in DelphiXE7 Options.
>>
>> Memory consumption reduced to half.
>>
>> Delphi XE7 is more stable now....
>>
>> Thanks.
> 
> Error Insight caches the information for later use.  This is why it uses more 
> memory on larger projects.  So does Code Insight.  During compiles there is dcu 
> caching going on.  Actually the IDE has very few minor leaks, what people calls 
> leaks are actually misunderstanding that there is caching going on and 
> intentional for performance reasons.
> 

It looks like the chacheing needs to free memory in low memory
situations at all or if he already does more/bigger parts and memory
fragmentation might be some issue as well.

Greetings

Markus

> few minor leaks, what people calls leaks are actually
> misunderstanding that there is caching going on and intentional for
> performance reasons.

But if the IDE bombs on you with an out of memory error, does it really
make andy difference to you if there are actual leaks, or if the
caching is faulty, or whatever other reason there might be for the
error?

-- 
Eivind Bakkestuen [NDD]

Jeff Overcash (TeamB) wrote:

> You are confusing the IDE caching information with memory leaks. A
> rising memory footprint <> memory leak.

Random "out of memory" usually puts me (and not me only) onto an idea
about leaks...

But as I already wrote:

> Update: according to the support page they have memory fragmentation
> and memory consuming features (Code Completion, Error Insight, and DCU
> cashing).
>
> In this case 64 bit will definitely help.

and

> But I think that 32 bit still has reserves: why not use memory mapped
> files, for example, to cash such big data?

Really, if I as 32 bit developer need more memory as it possible to
address in 32 bit app I think about memory mapped files first of all.

--
Alex

how do you disable error insight?
also that might help with XE8 too
(I cant move past XE6 with a large FMX -> OSX  project because of the out of memory issues with XE7 and XE8 (the later is worse)

Alex Belo wrote:

> Jeff Overcash (TeamB) wrote:
> 
> > You are confusing the IDE caching information with memory leaks. A
> > rising memory footprint <> memory leak.
> 
> Random "out of memory" usually puts me (and not me only) onto an idea
> about leaks...

Indeed. But in my experience, a few times it was a case of memory chips
going bad.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Computers can figure out all kinds of problems, except the
 things in the world that just don't add up." -- James Magary.

Rudy Velthuis (TeamB) wrote:

> Alex Belo wrote:
> 
> > Jeff Overcash (TeamB) wrote:
> > 
> > > You are confusing the IDE caching information with memory leaks. A
> > > rising memory footprint <> memory leak.
> > 
> > Random "out of memory" usually puts me (and not me only) onto an
> > idea about leaks...
> 
> Indeed. But in my experience, a few times it was a case of memory
> chips going bad.

Maybe, but I doubt that's the case for most people who are seeing this
problem.

The IDE absolutely has some legitimate memory management issues right
now.

-- 
Regards,
Bruce McGee
Glooscap Software

Brian,

| how do you disable error insight?

Tools | Options => Editor Options => Code Insight and then un-check the
Error Insight check-box.

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-06 19:22:09

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Bruce McGee wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > Alex Belo wrote:
> > 
> > > Jeff Overcash (TeamB) wrote:
> > > 
> > > > You are confusing the IDE caching information with memory
> > > > leaks. A rising memory footprint <> memory leak.
> > > 
> > > Random "out of memory" usually puts me (and not me only) onto an
> > > idea about leaks...
> > 
> > Indeed. But in my experience, a few times it was a case of memory
> > chips going bad.
> 
> Maybe, but I doubt that's the case for most people who are seeing this
> problem.
> 
> The IDE absolutely has some legitimate memory management issues right
> now.

+1. I can see that can be triggered when you recompile a package that
is required by other packages and even easier if there is a design time
package for the package that you recompile. This is from XE5 that is
the latest version I use.

Lajos Juhasz wrote:

> Bruce McGee wrote:
> 
> > Maybe, but I doubt that's the case for most people who are seeing
> > this problem.
> > 
> > The IDE absolutely has some legitimate memory management issues
> > right now.
> 
> +1. I can see that can be triggered when you recompile a package that
> is required by other packages and even easier if there is a design
> time package for the package that you recompile. This is from XE5
> that is the latest version I use.

Of course the flip side is that not everyone is seeing this behaviour.
I know I don't, and I leave the AIDE open for days at a time under low
memory conditions. And some of these projects and project groups are
reasonably non-trivial.

I wonder if it's because I don't usually work with packages?

I have a friend who gets bitten by this regularly. When he tells me
it's fixed, I will believe it.

-- 
Regards,
Bruce McGee
Glooscap Software

Lajos Juhasz wrote:

> Bruce McGee wrote:
> 
> > Maybe, but I doubt that's the case for most people who are seeing
> > this problem.
> > 
> > The IDE absolutely has some legitimate memory management issues
> > right now.
> 
> +1. I can see that can be triggered when you recompile a package that
> is required by other packages and even easier if there is a design
> time package for the package that you recompile. This is from XE5
> that is the latest version I use.

Of course the flip side is that not everyone is seeing this behaviour.
I know I don't, and I leave the AIDE open for days at a time under low
memory conditions. And some of these projects and project groups are
reasonably non-trivial.

I wonder if it's because I don't usually work with packages?

I have a friend who gets bitten by this regularly. When he tells me
it's fixed, I will believe it.

-- 
Regards,
Bruce McGee
Glooscap Software

Brian Hamilton Hamilton wrote:

> how do you disable error insight?

Really? Should not be too hard to find in the help files:

  http://docwiki.embarcadero.com/RADStudio/XE7/en/Code_Insight

Ninth table entry.


-- 
Rudy Velthuis        http://www.rvelthuis.de

"A clever man commits no minor blunders."
 -- Goethe (1749-1832)

Bruce McGee wrote:

> > > Random "out of memory" usually puts me (and not me only) onto an
> > > idea about leaks...
> > 
> > Indeed. But in my experience, a few times it was a case of memory
> > chips going bad.
> 
> Maybe, but I doubt that's the case for most people who are seeing this
> problem.
> 
> The IDE absolutely has some legitimate memory management issues right
> now.

Oh, sure. 

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Necessity is the plea for every infringement of human freedom.
 It is the argument of tyrants; it is the creed of slaves."
 -- William Pitt

Brian,

| how do you disable error insight?

Tools | Options => Editor Options => Code Insight and then un-check the
Error Insight check-box.

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-06 19:22:09

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Rudy,

| |  how do you disable error insight?
| 
| Really? Should not be too hard to find in the help files:
| 
|   http://docwiki.embarcadero.com/RADStudio/XE7/en/Code_Insight
| 
| Ninth table entry.

Nope!  that entry says nothing at all about how to disable Error
Insight. <g>

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-07 11:20:30

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

> Error Insight caches the information for later use.  This is why it uses more 
> memory on larger projects....there is caching going on and 
> intentional for performance reasons.

Eating up all the memory on the system is going to have the opposite effect of achieving performance. There needs to be an ability to cap the cache size in settings, and the default needs to be intelligent (x% of available system memory). On top of that, it should probably release cache memory if free memory on the system gets too low. 

In JetBrains' IDEs you can configure the maximum heap size the IDE will use, specify the largest code size it will use 
Intellisense on, etc.
https://intellij-support.jetbrains.com/entries/23395793-Configuring-JVM-options-and-platform-properties

> Nope!  that entry says nothing at all about how to disable Error
> Insight. <g>

There is actually a newish IDE feature that makes this easy:

Press F6 key

start typing error insight

when it shows up in the dropdown list, arrow down to it, press enter,
and the Options dialog opens on the correct page, and even with the
checkbox already the active control.

-- 
Eivind Bakkestuen [NDD]

Bruce,

> stuff that already works

That statement is questionable.

Regards,

Cesar Romero

> {quote:title=Jeff Overcash (TeamB) wrote:}{quote}
> Alex Belo wrote:
> > david hoke wrote:
> > 
> >> Is the source of the IDE available somewhere so that can be done by
> >> others than EMBT?
> > 
> > :-)
> > 
> > I mean "EMBT should fix memory leaks in IDE".
> > 
> 
> You are confusing the IDE caching information with memory leaks. A rising memory 
> footprint <> memory leak.

Caching is one thing.  But if it were just caching, the memory footprint should only rise
once.  When it rises every time you run a build, that's not [proper] caching; that's the
program leaking memory.

Bruce,

> stuff that already works

That statement is questionable.

Regards,

Cesar Romero

Mason Wheeler wrote:

> Caching is one thing.  But if it were just caching, the memory
> footprint should only rise once.  When it rises every time you run a
> build, that's not [proper] caching; that's the program leaking memory.

Not necessary, it can be also due to memory fragmentation.

Eivind,

| There is actually a newish IDE feature that makes this easy:
| 
| Press F6 key
| 
| start typing error insight
| 
| when it shows up in the dropdown list, arrow down to it, press enter,
| and the Options dialog opens on the correct page, and even with the
| checkbox already the active control.

Cool!  I wasn't aware of that capability.

Thanks!

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-08 13:00:38

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

ta! :)

Cesar Romero wrote:

> Bruce,
> 
> > stuff that already works
> 
> That statement is questionable.

Fair enough, but that's an argument to fix the bugs, not rip out all
traces of the .Net framework.

-- 
Regards,
Bruce McGee
Glooscap Software

Eivind Bakkestuen wrote:

> > Nope!  that entry says nothing at all about how to disable Error
> > Insight. <g>
> 
> There is actually a newish IDE feature that makes this easy:
> 
> Press F6 key
> 
> start typing error insight
> 
> when it shows up in the dropdown list, arrow down to it, press enter,
> and the Options dialog opens on the correct page, and even with the
> checkbox already the active control.

I'll be darned.  "Newish" includes XE2 FWIW.

Dan

Dan Barclay wrote:

> Eivind Bakkestuen wrote:
> 
> > There is actually a newish IDE feature that makes this easy:
> > 
> > Press F6 key
> > 
> > start typing error insight
> > 
> > when it shows up in the dropdown list, arrow down to it, press
> > enter, and the Options dialog opens on the correct page, and even
> > with the checkbox already the active control.
> 
> I'll be darned.  "Newish" includes XE2 FWIW.

Added in Delphi 2010.

-- 
Regards,
Bruce McGee
Glooscap Software

John Furlong wrote:

> On 04/06/2015 8:07 AM, Tugrul Tamturk wrote:
> > Hi,
> > 
> > Delphi XE7 IDE rapidly consume memory when loading and compiling my
> > project several times.
> > 
> > 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
> > 
> > Thanks
> > Tugrul
> > 
> For this reason, I am stuck on XE2 and won't (can't) upgrade until it 
> gets fixed (apparently XE8 still has the problem).
> 
>  From what I have read elsewhere, EMB thinks that the solution is a
> 64 bit IDE, and denies that there are any significant "memory leak"
> errors.

These are not really memory leaks, just a huge memory consumption due
to caches that are not released between compilation runs.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"It does me no injury for my neighbor to say there are twenty
 gods, or no God. It neither picks my pocket nor breaks my leg."
 -- Thomas Jefferson

Bruce McGee wrote:

> Fair enough, but that's an argument to fix the bugs, not rip out all
> traces of the .Net framework.

I don't think that all the .Net code inside IDE are bug free, is it
being fixed? This is the kind of code that I should evaluate to migrate
to Delphi, if I would be in charge.

Actually, I think that the one of the goals of the Castalia aquisition
may be replace some of those code.

External tools like MSBUILD should be keeped.


Regards,


Cesar Romero

On 09/06/2015 2:47 AM, Rudy Velthuis (TeamB) wrote:
> John Furlong wrote:
>
>>   From what I have read elsewhere, EMB thinks that the solution is a
>> 64 bit IDE, and denies that there are any significant "memory leak"
>> errors.
>
> These are not really memory leaks, just a huge memory consumption due
> to caches that are not released between compilation runs.
>
Perhaps so. However, presumably the reason to use a cache is to just 
improve performance (i.e. compile faster). It does not matter how fast a 
compile is, when it does not complete! The effective compile time goes 
to infinity :-0

A sensible caching scheme would not allow memory consumption to become 
so high that you can no longer compile at all. It would give up some 
performance in order to keep running. It seems to me that this is a 
design flaw which could be fixed, and its not necessary to convert to a 
64 bit implementation to do so. Of course, I am not implying that such a 
fix is easy.

J.

On 09/06/2015 2:47 AM, Rudy Velthuis (TeamB) wrote:
> John Furlong wrote:
>
>>   From what I have read elsewhere, EMB thinks that the solution is a
>> 64 bit IDE, and denies that there are any significant "memory leak"
>> errors.
>
> These are not really memory leaks, just a huge memory consumption due
> to caches that are not released between compilation runs.
>
Perhaps so. However, presumably the reason to use a cache is to just 
improve performance (i.e. compile faster). It does not matter how fast a 
compile is, when it does not complete! The effective compile time goes 
to infinity :-0

A sensible caching scheme would not allow memory consumption to become 
so high that you can no longer compile at all. It would give up some 
performance in order to keep running. It seems to me that this is a 
design flaw which could be fixed, and its not necessary to convert to a 
64 bit implementation to do so. Of course, I am not implying that such a 
fix is easy.

J.

John Furlong wrote:

> On 09/06/2015 2:47 AM, Rudy Velthuis (TeamB) wrote:
> > John Furlong wrote:
> > 
> >>   From what I have read elsewhere, EMB thinks that the solution is
> a >> 64 bit IDE, and denies that there are any significant "memory
> leak" >> errors.
> > 
> > These are not really memory leaks, just a huge memory consumption
> > due to caches that are not released between compilation runs.
> > 
> Perhaps so. However, presumably the reason to use a cache is to just 
> improve performance (i.e. compile faster). It does not matter how
> fast a compile is, when it does not complete! The effective compile
> time goes to infinity :-0
> 
> A sensible caching scheme would not allow memory consumption to
> become so high that you can no longer compile at all.

Oh, I'm sure it has its flaws, as the many complaints show. But I
assume that a restart of the IDE would be enough to reset the caches.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Computers make it easier to do a lot of things, but most of the
 things they make it easier to do don't need to be done."
 -- Andy Rooney.

Bruce McGee wrote:

> Fair enough, but that's an argument to fix the bugs, not rip out all
> traces of the .Net framework.

I don't think that all the .Net code inside IDE are bug free, is it
being fixed? This is the kind of code that I should evaluate to migrate
to Delphi, if I would be in charge.

Actually, I think that the one of the goals of the Castalia aquisition
may be replace some of those code.

External tools like MSBUILD should be keeped.


Regards,


Cesar Romero

> {quote:title=Lajos Juhasz wrote:}{quote}
> Mason Wheeler wrote:
> 
> > Caching is one thing.  But if it were just caching, the memory
> > footprint should only rise once.  When it rises every time you run a
> > build, that's not [proper] caching; that's the program leaking memory.
> 
> Not necessary, it can be also due to memory fragmentation.

Rather unlikely when using an anti-fragmenting memory manager like FastMM.

> {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> John Furlong wrote:
> 
> > On 04/06/2015 8:07 AM, Tugrul Tamturk wrote:
> > > Hi,
> > > 
> > > Delphi XE7 IDE rapidly consume memory when loading and compiling my
> > > project several times.
> > > 
> > > 64 bt IDE, pass 1 GB memory boundry is my URGENT NEED.
> > > 
> > > Thanks
> > > Tugrul
> > > 
> > For this reason, I am stuck on XE2 and won't (can't) upgrade until it 
> > gets fixed (apparently XE8 still has the problem).
> > 
> >  From what I have read elsewhere, EMB thinks that the solution is a
> > 64 bit IDE, and denies that there are any significant "memory leak"
> > errors.
> 
> These are not really memory leaks, just a huge memory consumption due
> to caches that are not released between compilation runs.

A memory leak is when memory, for any reason, remains in use after it is no
longer needed.  So yes, that is really a memory leak.

Mason Wheeler wrote:

> > These are not really memory leaks, just a huge memory consumption
> > due to caches that are not released between compilation runs.
> 
> A memory leak is when memory, for any reason, remains in use after it
> is no longer needed. 

But it if it cached, it is obviosuly regarded as still needed (why else
would one cache?). So not a leak.

And well, I don't accept your addition of "for any reason". I'd say it
is a leak if it happens inadvertently.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Not everything that can be counted counts, and not everything
 that counts can be counted." -- Albert Einstein

Mason Wheeler wrote:

> > These are not really memory leaks, just a huge memory consumption
> > due to caches that are not released between compilation runs.
> 
> A memory leak is when memory, for any reason, remains in use after it
> is no longer needed. 

But it if it cached, it is obviosuly regarded as still needed (why else
would one cache?). So not a leak.

And well, I don't accept your addition of "for any reason". I'd say it
is a leak if it happens inadvertently.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Not everything that can be counted counts, and not everything
 that counts can be counted." -- Albert Einstein

Mason Wheeler wrote:

> > These are not really memory leaks, just a huge memory consumption
> > due to caches that are not released between compilation runs.
> 
> A memory leak is when memory, for any reason, remains in use after it
> is no longer needed. 

But it if it cached, it is obviosuly regarded as still needed (why else
would one cache?). So not a leak.

And well, I don't accept your addition of "for any reason". I'd say it
is a leak if it happens inadvertently.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Not everything that can be counted counts, and not everything
 that counts can be counted." -- Albert Einstein

Rudy Velthuis (TeamB) wrote:
> John Furlong wrote:
>
>> On 09/06/2015 2:47 AM, Rudy Velthuis (TeamB) wrote:
>>> John Furlong wrote:
>>>
>>>>    From what I have read elsewhere, EMB thinks that the solution is
>> a >> 64 bit IDE, and denies that there are any significant "memory
>> leak" >> errors.
>>>
>>> These are not really memory leaks, just a huge memory consumption
>>> due to caches that are not released between compilation runs.
>>>
>> Perhaps so. However, presumably the reason to use a cache is to just
>> improve performance (i.e. compile faster). It does not matter how
>> fast a compile is, when it does not complete! The effective compile
>> time goes to infinity :-0
>>
>> A sensible caching scheme would not allow memory consumption to
>> become so high that you can no longer compile at all.
>
> Oh, I'm sure it has its flaws, as the many complaints show. But I
> assume that a restart of the IDE would be enough to reset the caches.

Nope, because a simple compile fills up the cache on the project I have 
here.
That means that we can't compile the project at all in the IDE.

Rudy Velthuis (TeamB) wrote:
> Mason Wheeler wrote:
>
>>> These are not really memory leaks, just a huge memory consumption
>>> due to caches that are not released between compilation runs.
>>
>> A memory leak is when memory, for any reason, remains in use after it
>> is no longer needed.
>
> But it if it cached, it is obviosuly regarded as still needed (why else
> would one cache?). So not a leak.
>
> And well, I don't accept your addition of "for any reason". I'd say it
> is a leak if it happens inadvertently.

Well, thing is, it does not release the cache, even when all projects 
have been closed.
To sum up, I open my big project, try to compile, get OOM errors. So I 
close all, and the memory goes down, but not to 300M. It stays up at 
around 1G.
And if I open again my big project, it stops with OOM errors way sooner.
So clearly, there is a (running) leak, which I believe is due to 
dependency loops in the cache.
This means that the initial reference to a unit is released, but units 
are depending on each other and their memory is never released, nor 
reused. It's a bit of memory floating in mid space...

On 09/06/2015 9:34 AM, Rudy Velthuis (TeamB) wrote:
>
But I assume that a restart of the IDE would be enough to reset the caches.
>
Of course that's the whole point. Having to restart the IDE after one or 
two compiles reduces productivity dramatically. Using an IDE is 
supposedly about improving productivity. For those with this problem, 
the IDE is simply not fit for purpose.

J.

"Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message 
news:725951@forums.embarcadero.com...
> Mason Wheeler wrote:
>>
>> A memory leak is when memory, for any reason, remains in use after it
>> is no longer needed.
>
> But it if it cached, it is obviosuly regarded as still needed (why else
> would one cache?). So not a leak.
>

If it is cached, and the _SAME_ compile/build is being repeated*, why would 
it need to acquire more?

Everything should have been cached from the first time - a repeat of the 
same build should NOT need anything more - eh?

*This sounds like the scenario being described ("having to restart the IDE 
after one or two compiles"), and would be common development procedure, 
since "we" tend to work in the same files repeatedly, for one given 
particular feature/modification.

Eivind Bakkestuen wrote:

> > Nope!  that entry says nothing at all about how to disable Error
> > Insight. <g>
> 
> There is actually a newish IDE feature that makes this easy:
> 
> Press F6 key
> 
> start typing error insight
> 
> when it shows up in the dropdown list, arrow down to it, press enter,
> and the Options dialog opens on the correct page, and even with the
> checkbox already the active control.

I'll be darned.  "Newish" includes XE2 FWIW.

Dan

John Furlong wrote:

> On 09/06/2015 9:34 AM, Rudy Velthuis (TeamB) wrote:
> > 
> But I assume that a restart of the IDE would be enough to reset the
> caches.
> > 
> Of course that's the whole point. Having to restart the IDE after one
> or two compiles reduces productivity dramatically. Using an IDE is 
> supposedly about improving productivity. For those with this problem, 
> the IDE is simply not fit for purpose.
> 
> J.

On more than one MS beta these were called either "undocumented
feature" or "unpleasant feature" for release builds.  Of course, those
terms aren't mutually exclusive.

Dan

> {quote:title=John Furlong wrote:}{quote}
> On 09/06/2015 9:34 AM, Rudy Velthuis (TeamB) wrote:
> >
> But I assume that a restart of the IDE would be enough to reset the caches.
> >
> Of course that's the whole point. Having to restart the IDE after one or 
> two compiles reduces productivity dramatically. Using an IDE is 
> supposedly about improving productivity. For those with this problem, 
> the IDE is simply not fit for purpose.

It's sad that this needs to be explained.

Joseph Mitzen wrote:

> > Of course that's the whole point. Having to restart the IDE after
> > one or two compiles reduces productivity dramatically. Using an IDE
> > is supposedly about improving productivity. For those with this
> > problem, the IDE is simply not fit for purpose.
> 
> It's sad that this needs to be explained.

Bullshit. I already said that it was a problem. But it is not a memory
leak.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"If the doctor told me I had only six minutes to live, I'd type
 a little faster."
 -- Isaac Asimov

david hoke wrote:

> "Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message
> news:725951@forums.embarcadero.com...
> > Mason Wheeler wrote:
> > > 
> > > A memory leak is when memory, for any reason, remains in use
> > > after it is no longer needed.
> > 
> > But it if it cached, it is obviosuly regarded as still needed (why
> > else would one cache?). So not a leak.
> > 
> 
> If it is cached, and the SAME compile/build is being repeated*, why
> would it need to acquire more?

Huh? Uuually you rebuild after you modified your code.


-- 
Rudy Velthuis        http://www.rvelthuis.de

"The man with a toothache thinks everyone happy whose teeth
 are sound." -- George Bernard Shaw

> {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> david hoke wrote:
> 
> > "Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message
> > news:725951@forums.embarcadero.com...
> > > Mason Wheeler wrote:
> > > > 
> > > > A memory leak is when memory, for any reason, remains in use
> > > > after it is no longer needed.
> > > 
> > > But it if it cached, it is obviosuly regarded as still needed (why
> > > else would one cache?). So not a leak.
> > > 
> > 
> > If it is cached, and the SAME compile/build is being repeated*, why
> > would it need to acquire more?
> 
> Huh? Uuually you rebuild after you modified your code.

OK, let's type this nice and slow so you'll understand it.

Imagine I have a project with two units, A and B.  I build, and it caches
A and B for build 1.  Let's call the cached units A1 and B1.

I change something minor in the implementation section of A and rebuild,
for build 2.  Cached unit B1 is still valid.  A1 is no longer valid and should
be removed from the cache, and replaced with A2.  Because A1 is being
removed and A2, which is about equal in size, is being added in to replace
it, *there should be no change in observed memory usage.*

This is not what we see occurring in practice. Therefore, there is obviously
a memory leak somewhere in the system.

Remember the old "ha ha but serious" joke that there are only two truly hard
problems in computer science: cache invalidation, naming things well, and
off-by-one errors.  Your assertion that because it's in the cache it must still
be needed and therefore it's not a memory leak fails on this point.

> {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> david hoke wrote:
> 
> > "Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message
> > news:725951@forums.embarcadero.com...
> > > Mason Wheeler wrote:
> > > > 
> > > > A memory leak is when memory, for any reason, remains in use
> > > > after it is no longer needed.
> > > 
> > > But it if it cached, it is obviosuly regarded as still needed (why
> > > else would one cache?). So not a leak.
> > > 
> > 
> > If it is cached, and the SAME compile/build is being repeated*, why
> > would it need to acquire more?
> 
> Huh? Uuually you rebuild after you modified your code.

OK, let's type this nice and slow so you'll understand it.

Imagine I have a project with two units, A and B.  I build, and it caches
A and B for build 1.  Let's call the cached units A1 and B1.

I change something minor in the implementation section of A and rebuild,
for build 2.  Cached unit B1 is still valid.  A1 is no longer valid and should
be removed from the cache, and replaced with A2.  Because A1 is being
removed and A2, which is about equal in size, is being added in to replace
it, *there should be no change in observed memory usage.*

This is not what we see occurring in practice. Therefore, there is obviously
a memory leak somewhere in the system.

Remember the old "ha ha but serious" joke that there are only two truly hard
problems in computer science: cache invalidation, naming things well, and
off-by-one errors.  Your assertion that because it's in the cache it must still
be needed and therefore it's not a memory leak fails on this point.

Mason Wheeler wrote:

> > {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> > david hoke wrote:
> > 
> > > "Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message
> > > news:725951@forums.embarcadero.com...
> > > > Mason Wheeler wrote:
> > > > > 
> > > > > A memory leak is when memory, for any reason, remains in use
> > > > > after it is no longer needed.
> > > > 
> > > > But it if it cached, it is obviosuly regarded as still needed
> > > > (why else would one cache?). So not a leak.
> > > > 
> > > 
> > > If it is cached, and the SAME compile/build is being repeated*,
> > > why would it need to acquire more?
> > 
> > Huh? Uuually you rebuild after you modified your code.
> 
> OK, let's type this nice and slow so you'll understand it.

Well, thank you for being so considerate.
> 
> Imagine I have a project with two units, A and B.  I build, and it
> caches A and B for build 1.  Let's call the cached units A1 and B1.
> 
> I change something minor in the implementation section of A and
> rebuild, for build 2.  Cached unit B1 is still valid.  A1 is no
> longer valid and should be removed from the cache, and replaced with
> A2.  Because A1 is being removed and A2, which is about equal in
> size, is being added in to replace it, *there should be no change in
> observed memory usage.*

As I said: I am aware of the fact that the scheme is not optimal. What
exactly is cached I don't know, and I don't know why the cache size
grows and I assume you don't know either.

Fact is that a growing cache is not necessarily a memory leak. OK? 

ISTM that problems only occur on systems that are close to the limit,
due to the size of the project(s) being compiled and due to the memory
limits on a 32 bit system. It would be nice if one could simply disable
the cache to see if that helps.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Earth provides enough to satisfy every man's need, but not
 every man's greed."
 --Mohandas Gandhi

Rudy Velthuis (TeamB) wrote:

> It would be nice if one could simply disable the cache to see if that
> helps.

I don't know if this "cash disabler" does this:

IDE Fix Pack 5.92
http://andy.jgknet.de/blog/ide-tools/ide-fix-pack/

"Changelog from 5.0 to 5.1 (2012-12-11)
Added: Disable Package Cache option in the installer"

--
Alex

Alex Belo wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > It would be nice if one could simply disable the cache to see if
> > that helps.
> 
> I don't know if this "cash disabler" does this:
> 
> IDE Fix Pack 5.92
> http://andy.jgknet.de/blog/ide-tools/ide-fix-pack/
> 
> "Changelog from 5.0 to 5.1 (2012-12-11)
> Added: Disable Package Cache option in the installer"

I don't think so.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Sailors ought never to go to church. They ought to go to hell,
 where it is much more comfortable." -- HG Wells.

Hi,

>>> Of course that's the whole point. Having to restart the IDE after
>>> one or two compiles reduces productivity dramatically. Using an IDE
>>> is supposedly about improving productivity. For those with this
>>> problem, the IDE is simply not fit for purpose.
>>
>> It's sad that this needs to be explained.
>
> Bullshit. I already said that it was a problem. But it is not a memory
> leak.

No Rudy. It _is_ a problem. This memory issues are not solved for a long 
time. The debugger consumes a large amount of memory (so much that the 
ide dies with a out of memory exception) if you have 10-20 (in our case) 
dlls compiled with remote debug symbols. With every new version of 
delphi we have to reduce the dlls we can debug simultanously. Get what? 
We have a .net solution in visual studio with nearly 100 assemblies. Not 
a single restart is needed. I have to restart the delphi ide after 2-3 
debug sessions.

Soeren

PS: My bosses have decided to switch the development tool. The delphi 
source code has grown over the last 10 years and we have to throw it 
away because our ide (delphi) is getting unstabler with every release 
and embt does _nothing_ to rise the product quality.

Hi,

 >>> Of course that's the whole point. Having to restart the IDE after
 >>> one or two compiles reduces productivity dramatically. Using an IDE
 >>> is supposedly about improving productivity. For those with this
 >>> problem, the IDE is simply not fit for purpose.
 >>
 >> It's sad that this needs to be explained.
 >
 > Bullshit. I already said that it was a problem. But it is not a memory
 > leak.

No Rudy. It _is_ a problem. This memory issues are not solved for a long 
time. The debugger consumes a large amount of memory (so much that the 
ide dies with a out of memory exception) if you have 10-20 (in our case) 
dlls compiled with remote debug symbols. With every new version of 
delphi we have to reduce the dlls we can debug simultanously. Get what? 
We have a .net solution in visual studio with nearly 100 assemblies. Not 
a single restart is needed. I have to restart the delphi ide after 2-3 
debug sessions.

Soeren

PS: My bosses have decided to switch the development tool. The delphi 
source code has grown over the last 10 years and we have to throw it 
away because our ide (delphi) is getting unstabler with every release 
and embt does _nothing_ to rise the product quality.

Soeren,

|  > Bullshit. I already said that it was a problem. But it is not a
| memory  > leak.
| 
| No Rudy. It is a problem.

Uhhh,... that's also what Rudy typed!  <g> 

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-16 10:32:09

Am 16.06.2015 um 16:00 schrieb Soeren Muehlbauer:

> 
> PS: My bosses have decided to switch the development tool. The delphi 
> source code has grown over the last 10 years and we have to throw it 
> away because our ide (delphi) is getting unstabler with every release 
> and embt does _nothing_ to rise the product quality.
> 

Hello,

you're exaggerate a little bit.
Do they enough quality wise? In my eyes no. Do they at least some
things? Definitely yes!

Greetings

Markus

Hi,

> |  > Bullshit. I already said that it was a problem. But it is not a
> | memory  > leak.
> |
> | No Rudy. It is a problem.
>
> Uhhh,... that's also what Rudy typed!  <g>

Maybe i misunderstood. I'm not a native english speaker. But i thought 
Rudy wrote "It was a problem" an meant the past.

Soeren

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>


-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>


-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

"Quentin Correll" <qcorrell@pacNObell.net> wrote in message 
news:726709@forums.embarcadero.com...
> Soeren,
>
> | Maybe i misunderstood. I'm not a native english speaker. But i
> | thought Rudy wrote "It was a problem" an meant the past.
>
> Ah.  In this case his use of "was" is related to the past-tense of HIS
> statement.
>
> [American] English has a lot of subtleties of interpretation like this.
> <g>
>

I agree about the meaning, but he technically should have used "is a 
problem" - I'm guessing he confused the past of "already said" into the 'was 
a problem' - very common, but I think nevertheless incorrect (and I am 
doubtless guilty of such failures as well.)

Quentin Correll wrote:

> Soeren,
> 
> >  Maybe i misunderstood. I'm not a native english speaker. But i
> >  thought Rudy wrote "It was a problem" an meant the past.
> 
> Ah.  In this case his use of "was" is related to the past-tense of HIS
> statement.
> 
> [American] English has a lot of subtleties of interpretation like
> this.  <g>
> 
> [Danged server isn't accepting posts! <grumble>]

Yes it is, it just isn't saying that it is. :-)  I've been deleting the
queued send requests when I start Xananews up the next time, and that
has caught most of my multiple posts, but not all.

-- 
Cheers,
Van

"Good judgment comes from experience, and a lot of that comes from bad
judgment." - Will Rogers

Quentin Correll wrote:

> Soeren,
> 
> >  Maybe i misunderstood. I'm not a native english speaker. But i
> >  thought Rudy wrote "It was a problem" an meant the past.
> 
> Ah.  In this case his use of "was" is related to the past-tense of HIS
> statement.
> 
> [American] English has a lot of subtleties of interpretation like
> this.  <g>
> 
> [Danged server isn't accepting posts! <grumble>]

Yes it is, it just isn't saying that it is. :-)  I've been deleting the
queued send requests when I start Xananews up the next time, and that
has caught most of my multiple posts, but not all.

-- 
Cheers,
Van

"Good judgment comes from experience, and a lot of that comes from bad
judgment." - Will Rogers

Alex Belo wrote:

> I don't know if this "cash disabler" does this:

The "package cache" has nothing to do with the amount of memory used by
the IDE.

The "package cache" caches the component names and glyphs that are in
the ToolPalette in the Registry instead of reading them from the
design-time packages. By disabling the IDE doesn't use the slow
registry access but instead loads the data from the BPL's exported
"Register" function.

The memory "leak" everybody talks about is that the compiler, debugger
and ErrorInsight (and with XE8: Castalia) eat a lot of memory. I know
for sure that ErrorInsight is using a lot of memory (.NET objects) when
it has to read generics from DCU or PAS files (at least that's what it
did in XE3). I haven't look into it after XE3 because I disabled
ErrorInsight due to the many false positives (my code was more red then
white).


-- 
Andreas Hausladen

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Soeren,

| Maybe i misunderstood. I'm not a native english speaker. But i
| thought Rudy wrote "It was a problem" an meant the past.

Ah.  In this case his use of "was" is related to the past-tense of HIS
statement.

[American] English has a lot of subtleties of interpretation like this.
<g>

[Danged server isn't accepting posts! <grumble>]

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 10:37:20

Quentin,

Looks like it was but not telling XN.  ROFL!

-- 

   Q  --  XanaNews 1.19.1.372 -  2015-06-18 14:47:25

Andreas Hausladen wrote:

> The "package cache" has nothing to do with the amount of memory used
> by the IDE.
> 
> The "package cache" caches the component names and glyphs that are in
> the ToolPalette

Ok, thank you for information.

--
Alex

> {quote:title=Tugrul Tamturk wrote:}{quote}
> Delphi XE7 IDE rapidly consume memory when loading and compiling my project several times.

I can compile 2.5 apps before the IDE goes out of memory.
https://www.youtube.com/watch?v=k2Vd4PktUiA
--
http://plus.lars.fosdal.com
Delphi Developers Google+ Community: https://plus.google.com/communities/103113685381486591754

Hello david,

david hoke wrote:

> Is the source of the IDE available somewhere so that can be done by
> others than EMBT?

Yes, it is called the Lazarus project. ;-)

G.