AS7 High CPU Usage When Opening a Large SAM4E Project

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've developing a large embedded networking project using SAM4E and am having an issue with Atmel Studio 7 (version 7.0.1188; the issue occurred on all previous versions of AS7 as well). When the project is opened (and successfully loaded), CPU usage goes through the roof for several minutes. During this time the IDE is all but unusable -- clicks take seconds to register, scrolling is jumpy, and opening files or navigating the solution is a pain. Compilation is not affected. The problem eventually subsides but reappears the next time a project is opened.

 

My current workaround is to simply not close the project, but I've lately had a smattering of debugger sessions crash and force AS7 to reload and thus reopen the project.

 

Has anyone else encountered a similar problem? How are you dealing with it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After more research I think this is an issue with the core Atmel Studio 7 (or Visual Studio shell) itself.

 

All extensions were uninstalled except for toolchain and GDB, and the problem persisted. I then started up Sysinternals Process Monitor and found that upon opening the project file, Atmel Studio is going through about 5.4-5.5 million 'ReadFile' operations over a span of 6 minutes and 45 seconds. The type of drive media doesn't seem to matter much at all (similar time for HDD, SSD, and RAM disk). Here's the file makeup of the project:

 

    252 source files totaling 6.3 MB
    395 header files totaling 5.1 MB

 

Some files are accessed a few hundred times, while others are in the tens of thousands of reads. Why? What is AS7 doing at this time? Is it performing a (very slow) database rebuild every time the project is loaded?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are screenshots of an example of the problem using an Atmel SAM4E sample project: WDT_EXAMPLE1.

 

http://imgur.com/a/XQgNs

 

Here's the file makeup of the project:

 

    18 source files totaling 234 KB
    130 header files totaling 2.2 MB

 

1 million 'ReadFile' events. That's insane! Similar behavior to my much larger project, but because WDT_EXAMPLE1 is smaller in size it takes only 22 seconds until the sluggish performance goes away.

Last Edited: Wed. Nov 9, 2016 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I experience the same behaviour. Larger C++ Project for SAME70, takes quite a while for the IDE to become responsive after loading.

Do you use a C or C++ Project?

My wild guess was, that it might be the Visual Assist Plugin, as it parses the whole code. But as I said it is only a wild guess.

When you uninstalled all Plugins, did you also uninstall Visual Assist X and the problem was still occuring?

Last Edited: Thu. Nov 10, 2016 - 12:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is a C project.

 

VAssistX was my first inkling and thus the first plugin to be uninstalled, and it made no perceptible difference.

 

Here is my working theory on the Atmel Studio bug: upon project open the IDE is attempting to find relationships within the code. Instead of reading the contents of all project source and header files into memory and then doing the processing, the IDE is parsing all the files a handful of bytes at a time from the disk. The read operation requests 4096 bytes at different file indices (usually no more than 20 bytes away from a previous read). It does this for every file in the project, and, to make matters worse, it is all done on the UI thread. For a project with about 6 MB of source code there are 5.5 million ReadFile operations. A smaller project with about 1.1 MB of source yields almost 1 million ReadFile operations. I don't think the directly proportional relationship is a coincidence.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still having same issues even in Atmel 7.0.1645. I submitted a bug report but they wanted me to make a video of when it's behaving slow and kept insisting they don't experience this issue... I usually go for a tea when having to restart the IDE :)

Last Edited: Thu. May 24, 2018 - 09:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed, it is still a problem with 7.0.1645. With the original bug report I submitted screenshot evidence of the readfile operations along with timestamps to show how long the process of loading a simple project and scouring the files in the project takes. If the development team cannot reproduce the issue it's because there's something oddly specific with hardware and/or software configuration on the machines I use on a daily basis, or because they're not paying objective attention to what is happening.

 

Steps to reproduce:

 

  1. open a large project in the IDE
  2. navigate source .h/.c files
  • scrolling will be slow
  • UI will be unresponsive for seconds at a time
  • use SysInternals Process Monitor to analyze AtmelStudio.exe

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the screenshot it looks like the project is on your R: drive.  Is this a network drive?  Loading my local projects running off a SSD are much faster than hitting a network drive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not a network drive. The R drive on this machine is an M.2 NVMe SSD.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Same behaviour here but up to several minutes, I'm loading the project made of .cpp, .c, .h files from a SSD 750 EVO 500GB drive. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So mine is not exactly zippy fast, but nowhere near what you describe.  I ran process monitor after a fresh reboot and starting a fairly large AS project.  The one thing different I see with my log is the file reads are all FASTIO_READ instead of READFILE.  This means the operating system is properly caching the reads in my case, but is likely going straight to disk in yours.  So start with Windows cache management and disk performance - virtual memory, paging file, enough RAM in the system, disable virus scanners, check M.2 performance with CrystalDiskMark, etc.  For reference I'm running the latest AS on Win10, a fairly slow Core I3, and a SSD.  But I'm using 16GB RAM and a pretty small swap file to minimize virtual memory paging.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My PC is Windows 10 Pro with default settings, pretty recent CPU running i7-4710HQ at 2.5GHz, 16GB. Other environments (Eclipse based or Visual Studio 2015) load projects fast. I noticed this behaviour occurs just after projects were loaded and Visual Assist finished parsing until I see no other status information in status bar but then scrolling and editing text (maximum 1000 lines files, 80 characters in average) becomes slow for a few minutes and then returns to normal.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Visual Assist - play with these settings, they look promising...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All those options were disabled long time ago in another attempt to fix this issue as suggested before by guys from Microchip. I also tried with VAssistX completely disabled. It still slows down to a crawl... Now that you mentioned I'm surprised why the status bar displayed "VA: Parsing" message if that option was already disabled. 

 

Last Edited: Thu. May 24, 2018 - 04:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to re-surface an old thread, but has anybody figured out this issue?  I'm running 7.0.1645 and it drives me a bit crazy to wait so long each time I have to launch after it crashes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your timing is awesome.  I'm seeing this same problem now.  I've recently added GMAC support and lwIP to get TCP/IP into my SAME70 project.  The file count has increased.  And guess what?  CPU usage hovers around 35% when Atmel Studio is sitting idle.  The IDE is unusable/non-responsive/exceptionally slow to respond.  I've disabled VXAssist as well with no effect.  Currently using Atmel Studio v7.0.1645, not the latest versions but it was well behaved until the past few weeks.  The only difference I'm aware of is adding a lot of new files to the project.

 

I have a new software development computer coming in a few weeks and will install a fresh copy of AS at that time, probably the latest version.  I'm hoping things improve.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A new install won't help.  I just built a new computer and this problem persists.  I have a solution with about 8 projects and every time I load a project it goes through the high CPU exercise.  Thankfully the new CPU does it faster than the old one.  I think this is related to the Visual Studio core doing processing, and my guess is this is for Intellisense support. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Same here on 3 different computers, a long time to wait when loading E54 project with LWIP and about some 100 source files in AS7.

XEON six core 32GB DDR3, i7 mobile 8GB or old Dual core 4GB, same slow behavior and processing power seems no to help much with this.

At the XEON with RAID0 Adaptec on 4 fast velociraptor or on fast SSD, i have to wait several minutes before AS7 is usable.

Compare test with Segger ES the project loads below 10s, but only the source files are the same, segger uses an own project file.

When will Microchip give us an update for this ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So new computer is up and running.  It's a beast of a machine - Core i9-9900K, 16GB DDR4-3600, NVME m.2 storage, you name it.  I'm seeing a 11X improvement in compile times on the large project (2 min 10 secs before, 11.4 secs now).  Very happy.

 

But even with this new powerhouse of a development computer the IDE is still non-responsive, sluggish, and unusable immediately after loading a project and for upwards of five minutes or so.  Task manager shows CPU usage for the Atmel Studio 7.0 process as high during that time.  There's definitely a problem with the Atmel IDE immediately after loading large projects.