Board index » cppbuilder » Slow debug after making changes

Slow debug after making changes

I've noticed that running a fully compiled app with debugging is much
slower after I've made changes. If I open a project and make it, the
following Run takes about 12 secs. (from clicking run until I see my
main form)  After changing and remaking a file, all successive Run
takes over 40 secs. If I close the project and repoen it, the
initial run drops back to 12 secs.  Has anybody else seen this?

It's aggravating becuase most of the time (about 30 secs.) is after
the compile dialog has gone away and their is no apparent disk
activity. Peformance monitor shows the CPU pegged at 100% the entire
time   This is a fairly large project (3.8 meg exe) and I'm running a
350MHZ Pentium II with 256Meg of memory  and SCSI drives. Everyone on
my project now has at lease a 333MHZ Pentium II with 128 meg of RAM.
Anything less was unacceptable performance wise.

 

Re:Slow debug after making changes


Quote
> slower after I've made changes. If I open a project and make it, the
> following Run takes about 12 secs. (from clicking run until I see my
> main form)  After changing and remaking a file, all successive Run
> takes over 40 secs. If I close the project and repoen it, the
> initial run drops back to 12 secs.  Has anybody else seen this?

You might try closing a bunch of the project windows.  I have heard that
if you don't have the project manager open it speeds things up.

+===================================================+
| Jonathan Arnold (mailto:jdarn...@buddydog.org)    |
| Senior Engineer           Roger Wagner Publishing |
| http://people.ne.mediaone.net/jdarnold            |
+===================================================+

"There is no psychiatrist in the world like a puppy{*word*180}ing your
 face." -- Ben Williams

Re:Slow debug after making changes


Quote
Preferred Customer wrote:

> I've noticed that running a fully compiled app with debugging is much
> slower after I've made changes. If I open a project and make it, the
> following Run takes about 12 secs. (from clicking run until I see my
> main form)  After changing and remaking a file, all successive Run
> takes over 40 secs. If I close the project and repoen it, the
> initial run drops back to 12 secs.  Has anybody else seen this?

I haven't noticed this time change (between a new project and a
modified project.)  Hmmm.  The startup lag in general is quite
mysterious to me.  My console application takes about 10 seconds to
start, and it's fairly simple.

--
Chris (TeamB)

Re:Slow debug after making changes


Quote
Leighton Braddock wrote:

> Are you using the STL?

Yes.  In fact, I pretty sure there's a link.  But maybe it's templates
in general.  Maybe it's doing a lot of work to decide if it needs to
recompile or not.

--
Chris (TeamB)

Re:Slow debug after making changes


Quote
Leighton Braddock wrote:

> I dont think its trying to decide.
> That work is done before the designers disapear.

You're probably right.  

Quote
> Is Inprise aware of this?

I don't know, but odds are very good that they do.  I'm trying to find
this out.

Quote
> What is TeamB?

Here is the "canned answer":

  "Those of us with (TeamB) after our names are not Inprise employees
but a group of folks that have volunteered to assist Inprise and help
fellow users who have questions about the operation of the products."
--
Chris (TeamB)

Re:Slow debug after making changes


Are you using the STL?
A few people who have mentioned how slow the de{*word*81} is have also said that
they are using the STL. Maybe there's a connection?

I am experience similar, but worse, delay problems.

One thing that I found that helps is to make sure that none of the dlls that
the project is using have accompaning .tds files.

Quote
Preferred Customer wrote in message

<01bdb50a$19ebdbf0$e24f08d0@f96zt-tstewart>...
Quote
>I've noticed that running a fully compiled app with debugging is much
>slower after I've made changes. If I open a project and make it, the
>following Run takes about 12 secs. (from clicking run until I see my
>main form)  After changing and remaking a file, all successive Run
>takes over 40 secs. If I close the project and repoen it, the
>initial run drops back to 12 secs.  Has anybody else seen this?

>It's aggravating becuase most of the time (about 30 secs.) is after
>the compile dialog has gone away and their is no apparent disk
>activity. Peformance monitor shows the CPU pegged at 100% the entire
>time   This is a fairly large project (3.8 meg exe) and I'm running a
>350MHZ Pentium II with 256Meg of memory  and SCSI drives. Everyone on
>my project now has at lease a 333MHZ Pentium II with 128 meg of RAM.
>Anything less was unacceptable performance wise.

Re:Slow debug after making changes


I dont think its trying to decide.
That work is done before the designers disapear.

Is Inprise aware of this?
What is TeamB?

Quote
Chris Uzdavinis (TeamB) wrote in message

<35B655C5.27C2C...@uzdavinis.com>...
Quote
>Leighton Braddock wrote:

>> Are you using the STL?

>Yes.  In fact, I pretty sure there's a link.  But maybe it's templates
>in general.  Maybe it's doing a lot of work to decide if it needs to
>recompile or not.

>--
>Chris (TeamB)

Re:Slow debug after making changes


Quote
> Are you using the STL?

No, I'm not using STL, but we do use our own templates extensively.

Quote
> One thing that I found that helps is to make sure that none of the
dlls that
> the project is using have accompaning .tds files.

As for deleteing the .tds file, that does make it a lot faster (2
secs.) However, this file is used by the integrated de{*word*81}.
Deleting it is the same as turning off integrated debugging, which is
not what I want. Also, you have to
close you're project to delete the file, and if you make and changes
and integrated debugging is on, it gets recreated.

Todd Stewart (Formally Preferred Customer)
Leighton Braddock <bradd...@ww.co.nz> wrote in article
<6p5jas$mv...@forums.borland.com>...

Re:Slow debug after making changes


Quote
> Yes.  In fact, I pretty sure there's a link.  But maybe it's
templates
> in general.  Maybe it's doing a lot of work to decide if it needs
to
> recompile or not.

Maybe it is templates in general. I don't use STL, but do use
templates extensively.

Other Threads