Super slow with KDS 3.2

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Super slow with KDS 3.2

849 Views
davidsherman
Senior Contributor I

I had this problem in KDS 3.0, and increasing the Ecplise stack size kinetis-design-studio.ini. seemed to fix the problem:

 

-Xmx1024m

 

However, KDS 3.2 is having the same problem, but the same change isn't fixing it.

 

The symptom is it starts out building quickly, but subsequent builds get slower and slower to where it takes 10 minutes to build something that only took 15 seconds to build before.  Once I reboot the computer, it's back to building quickly, but eventually it slows down again.  The worst part is that it leaves everything running very slowly; if I close KDS 3.2 and switch to KDS 3.0 for older projects, it's taking forever to build and the whole machine is being very sluggish, with the CPU usage stuck at 90-100%.

 

Parallel builds are enabled.  Builds are local to the machine.  Any ideas?

Labels (1)
0 Kudos
7 Replies

583 Views
davidsherman
Senior Contributor I

I can't explain it, but while investigating a different issue on a different version of KDS, I tried updating the make utilities for 3.2, and it seems to have fixed it.  Still no idea what the problem was, but Erich's article helped.

https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fmcuoneclipse.com%2F2015%2F03%2F29%2Fs... 

0 Kudos

583 Views
davidsherman
Senior Contributor I

Well, things are still not great compared to KDS 3.0.  After 4-5 builds, it goes from taking 10-20 seconds for a build to 5 minutes or more.  Another annoying aspect; if I start a build, it won't stop when I click cancel.  It just hangs forever thinking it's still building, and I have to kill off the whole KDS process.  The paths seem to be correct, is there a nice way of finding out if it is having a problem with a path?

0 Kudos

583 Views
bobpaddock
Senior Contributor III

Sounds like a memory leak.  Any differences in drivers for programmers/debuggers?  If they are not attached does anything change?

Sysinternals Process Utilities may shed some light on what process(s) may be leaking memory.

0 Kudos

583 Views
bobpaddock
Senior Contributor III
0 Kudos

583 Views
davidsherman
Senior Contributor I

Thanks Erich and Bob, I think I've improved it, for some reason it was stuck using 256MB of heap, even though I had changed Xmx to 1024.  I changed Xms to 1024 as well, and it's much happier now.  Still slows down a bit on subsequent builds, but not as bad as before.

0 Kudos

583 Views
bobpaddock
Senior Contributor III

Having non-existent directories in the PATH can slow GCC to a crawl.

0 Kudos

583 Views
BlackNight
NXP Employee
NXP Employee

Hi David,

can you check the heap usage (see https://mcuoneclipse.com/2015/07/31/improve-eclipse-performance-with-increased-heap-size/ ) if it grows too much?

It seems to me that it is not really Eclipse/KDS related: both 3.0 and 3.2 are using the same Eclipse. There is one difference: KDS 3.2.0 is using the GNU ARM Eclipse (GNU ARM Eclipse - Browse /Build Tools at SourceForge.net ) build utilities (located in C:\nxp\KDS_3.2.0\bin) to support >8192 command line length.

To find out if this somehow is causing what you describe, you could rename that bin folder (so you have a backup) and copy the one from KDS v3.0.0?

Other thoughts: maybe Windows is triggering some file indexing services or other things slowing down your machine?

I hope this helps,

Erich

0 Kudos