|
Replies:
94
-
Last Post:
Aug 11, 2015 3:23 PM
Last Post By: Graeme Geldenhuys
|
|
|
Posts:
5
Registered:
9/24/98
|
|
|
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
|
|
|
Posts:
626
Registered:
10/8/06
|
|
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 |
|
|
|
|
Posts:
616
Registered:
2/9/07
|
|
"Alex Belo" <b dot a dot v at inbox dot ru> wrote in message
news:725618 at forums dot embarcadero dot 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? |
|
|
|
|
Posts:
626
Registered:
10/8/06
|
|
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 |
|
|
|
|
Posts:
1,529
Registered:
9/23/99
|
|
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) |
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
Jeff Overcash (TeamB) wrote:
A rising memory
footprint <> memory leak.
True that.
--
Nick
Delphi Programming is Fun |
|
|
|
|
Posts:
626
Registered:
10/8/06
|
|
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 |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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. |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
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 |
|
|
|
|
Posts:
801
Registered:
3/14/14
|
|
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. |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
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 |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
37
Registered:
4/15/05
|
|
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. |
|
|
|
|
Posts:
801
Registered:
3/14/14
|
|
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. |
|
|
|
|
Posts:
37
Registered:
4/15/05
|
|
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. |
|
|
|
|
Posts:
152
Registered:
5/25/01
|
|
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. |
|
|
|
|
Posts:
74
Registered:
2/22/08
|
|
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... |
|
|
|
|
Posts:
5
Registered:
9/24/98
|
|
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 |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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. |
|
|
|
|
Posts:
424
Registered:
8/26/01
|
|
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. |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
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. |
|
|
|
|
Posts:
889
Registered:
11/9/03
|
|
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 |
|
|
|
|
Posts:
392
Registered:
6/9/02
|
|
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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
26
Registered:
11/29/99
|
|
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. |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
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 |
|
|
|
|
Posts:
26
Registered:
11/29/99
|
|
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. |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
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 |
|
|
|
|
Posts:
26
Registered:
11/29/99
|
|
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 |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
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 |
|
|
|
|
Posts:
616
Registered:
2/9/07
|
|
"Quentin Correll" <qcorrell at pacNObell dot net> wrote in message
news:726709 at forums dot embarcadero dot 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.) |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
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 |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
397
Registered:
6/28/03
|
|
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 |
|
|
|
|
Posts:
397
Registered:
6/28/03
|
|
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 |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
Quentin,
Looks like it was but not telling XN. ROFL!
--
Q -- XanaNews 1.19.1.372 - 2015-06-18 14:47:25
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
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
|
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
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. |
|
|
|
|
Posts:
37
Registered:
4/15/05
|
|
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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
424
Registered:
8/26/01
|
|
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... |
|
|
|
|
Posts:
616
Registered:
2/9/07
|
|
"Rudy Velthuis (TeamB)" <newsgroups at rvelthuis dot de> wrote in message
news:725951 at forums dot embarcadero dot 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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
david hoke wrote:
"Rudy Velthuis (TeamB)" <newsgroups at rvelthuis dot de> wrote in message
news:725951 at forums dot embarcadero dot 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 |
|
|
|
|
Posts:
37
Registered:
4/15/05
|
|
david hoke wrote:
"Rudy Velthuis (TeamB)" <newsgroups at rvelthuis dot de> wrote in message
news:725951 at forums dot embarcadero dot 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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
Mason Wheeler wrote:
david hoke wrote:
"Rudy Velthuis (TeamB)" <newsgroups at rvelthuis dot de> wrote in message
news:725951 at forums dot embarcadero dot 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 |
|
|
|
|
Posts:
626
Registered:
10/8/06
|
|
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 |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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. |
|
|
|
|
Posts:
46
Registered:
6/5/00
|
|
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 |
|
|
|
|
Posts:
626
Registered:
10/8/06
|
|
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 |
|
|
|
|
Posts:
37
Registered:
4/15/05
|
|
david hoke wrote:
"Rudy Velthuis (TeamB)" <newsgroups at rvelthuis dot de> wrote in message
news:725951 at forums dot embarcadero dot 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. |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
96
Registered:
5/25/98
|
|
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. |
|
|
|
|
Posts:
5
Registered:
9/24/98
|
|
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. |
|
|
|
|
Posts:
556
Registered:
10/14/04
|
|
|
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)
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
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 |
|
|
|
|
Posts:
556
Registered:
10/14/04
|
|
ta! |
|
|
|
|
Posts:
7,731
Registered:
9/22/99
|
|
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
|
|
|
|
Posts:
447
Registered:
5/8/01
|
|
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] |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
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 |
|
|
|
|
Posts:
889
Registered:
11/9/03
|
|
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 |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
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 |
|
|
|
|
Posts:
889
Registered:
11/9/03
|
|
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 |
|
|
|
|
Posts:
2,412
Registered:
12/1/99
|
|
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 |
|
|
|
|
Posts:
189
Registered:
9/30/99
|
|
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/ |
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
3
Registered:
7/24/13
|
|
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" ? |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
P Tytgat wrote:
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 |
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
16
Registered:
9/10/00
|
|
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.
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 |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
Bruce,
stuff that already works
That statement is questionable.
Regards,
Cesar Romero |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
Bruce,
stuff that already works
That statement is questionable.
Regards,
Cesar Romero |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
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 |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
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 |
|
|
|
|
Posts:
462
Registered:
3/22/00
|
|
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 |
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
5
Registered:
9/24/98
|
|
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. |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
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 |
|
|
|
|
Posts:
2,414
Registered:
9/22/99
|
|
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 |
|
|
|
|
Posts:
1,716
Registered:
9/30/99
|
|
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 |
|
|
|
|
Posts:
1,529
Registered:
9/23/99
|
|
Tugrul Tamturk wrote:
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) |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
Am 05.06.2015 um 19:39 schrieb Jeff Overcash (TeamB):
Tugrul Tamturk wrote:
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 |
|
|
|
|
Posts:
447
Registered:
5/8/01
|
|
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] |
|
|
|
|
Posts:
392
Registered:
6/9/02
|
|
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 |
|
|
|
|
Posts:
5,113
Registered:
11/9/03
|
|
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 |
|
|
|
|
Posts:
156
Registered:
10/26/99
|
|
|
|
|
Legend
|
|
Helpful Answer
(5 pts)
|
|
Correct Answer
(10 pts)
|
|
Connect with Us