AVR Freaks

Tools, Atmel Studio (ARM-related)

Level: New Member

Joined: Thu. Feb 7, 2008

Posts: 13 View posts

Posted by stevenpickles: Mon. Nov 7, 2016 - 06:23 PM

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?

Tags:

Level: New Member

Joined: Thu. Feb 7, 2008

Posts: 13 View posts

Posted by stevenpickles: Wed. Nov 9, 2016 - 05:24 PM

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?

Level: New Member

Joined: Thu. Feb 7, 2008

Posts: 13 View posts

Posted by stevenpickles: Wed. Nov 9, 2016 - 06:37 PM

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

adjsw

Level: New Member

Joined: Wed. Sep 7, 2016

Posts: 15 View posts

Posted by adjsw: Thu. Nov 10, 2016 - 12:23 PM (Reply to #3)

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

Level: New Member

Joined: Thu. Feb 7, 2008

Posts: 13 View posts

Posted by stevenpickles: Thu. Nov 10, 2016 - 01:26 PM (Reply to #4)

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.

Level: Wannabe

Joined: Thu. Nov 5, 2015

Posts: 56 View posts

Posted by davidluca3000: Thu. May 24, 2018 - 09:41 AM (Reply to #5)

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

Level: New Member

Joined: Thu. Feb 7, 2008

Posts: 13 View posts

Posted by stevenpickles: Thu. May 24, 2018 - 12:33 PM

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:

open a large project in the IDE
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

Level: Hangaround

Joined: Fri. Jul 14, 2017

Posts: 168 View posts

Posted by ScottMN: Thu. May 24, 2018 - 12:59 PM

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.

Level: New Member

Joined: Thu. Feb 7, 2008

Posts: 13 View posts

Posted by stevenpickles: Thu. May 24, 2018 - 01:03 PM

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

Level: Wannabe

Joined: Thu. Nov 5, 2015

Posts: 56 View posts

#10

Posted by davidluca3000: Thu. May 24, 2018 - 01:04 PM (Reply to #8)

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.

Level: Hangaround

Joined: Fri. Jul 14, 2017

Posts: 168 View posts

#11

Posted by ScottMN: Thu. May 24, 2018 - 02:26 PM

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.

Level: Wannabe

Joined: Thu. Nov 5, 2015

Posts: 56 View posts

#12

Posted by davidluca3000: Thu. May 24, 2018 - 02:59 PM

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.

Level: Hangaround

Joined: Fri. Jul 14, 2017

Posts: 168 View posts

#13

Posted by ScottMN: Thu. May 24, 2018 - 03:10 PM

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

Level: Wannabe

Joined: Thu. Nov 5, 2015

Posts: 56 View posts

#14

Posted by davidluca3000: Thu. May 24, 2018 - 03:39 PM (Reply to #13)

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

ryanpatterson

Level: New Member

Joined: Thu. Jan 17, 2019

Posts: 1 View posts

#15

Posted by ryanpatterson: Thu. Jan 17, 2019 - 06:02 AM

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.

Level: Hangaround

Joined: Fri. Jul 14, 2017

Posts: 168 View posts

#16

Posted by ScottMN: Thu. Jan 17, 2019 - 02:13 PM

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.

tscharf

Level: New Member

Joined: Fri. Jan 18, 2019

Posts: 6 View posts

#17

Posted by tscharf: Fri. Jan 18, 2019 - 01:51 PM

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.

t-erdmann@web.de

Level: New Member

Joined: Wed. Feb 16, 2005

Posts: 2 View posts

#18

Posted by t-erdmann@web.de: Mon. Jan 21, 2019 - 03:53 PM (Reply to #17)

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 ?