This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

code composer memory usage for growing project

I have found that as my development project has grown that code composer consumes a large amount of memory and is getting sluggish.  After opening CCS and opening my project, I double click on a source file and it takes ~1 minute for it to open in the window.  If I open windows task manager, CCS has pegged one of my dual cores for cpu cycles and the memory usage slowly climbs forever ( about 80kb/second, I have seen it reach over 400MB used even if I do nothing more than open my project).  I have 26 source files and 1 library in my project.  I recently upgraded to the latest ccs & compiler but with no change.  Is there anything that might be causing this or any organization solutions or am I doomed to slow performance and an apparent memory leak?

  • I have seen this sort of thing happen before with certain projects though usually if you end up with ludicrous memory usage it is during build as opposed to opening the project, my first thought on this would be that something is messed up in the project itself, it may be worth making a new project and adding your source files to it to see if that improves things.

    When it takes the source file over a minute to open is that all source files or just a certain one? I ask because I have seen the editor get hung up on some particular source files, often when there are strange hidden characters or a particular sequence in the comments. This being said you may be able to narrow down the issue from CCS in general to the editor itself by changing the default CCS editor to use an external editor (like notepad.exe) at least temporarily.

  • In trying to track down the issue, I started with a fresh project and gradually added files back in.  I cleaned up some hairy #include chains and it seems to work much faster without the memory leak.  So I don't know if it was placing #include statements in #include files or if the project just somehow got in a bad state.