We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
I have a problem with compilation time with Keil uVision.
If I have enabled Debug info and Browse info, recompiling project takes very long time. Comparing to other computers the same project on my computer takes more than twice longer.
My computer: CPU: Inter CORE i7, 2.4GHz Memory: 8GB DDR3 1600MHz Disk: 256 SSD
Comparing to friends computer with I3 and without SSD disk drive, my compilation takes about 2 times longer.
I'm sure there is some workaround to speed this up.
Any ideas?
Thanks in advance.
First off - an I3 is quite powerful and can beat a number of I7 machines depending on type of tasks. Extra cores aren't an advantage if the tools aren't making use of them. And a two-core I3 can manage quite impressive turbo speeds without worrying about total power consumption and temperature.
Next thing - your compile times can be greatly affected by amount of free RAM.
And a machine with SDD without TRIM support and heavily fragmented, making the disk controller having to desperately move large amounts of file data around to find flash sectors to erase and reuse can be slower than a HDD on a machine with lots of free RAM to cache file accesses.
Have you made sure you test in identical conditions? Have you checked if it's the compilation or the linking that makes the biggest difference? Have you looked at CPU load, RAM state, amount of paging operations etc while building on the two machines?
Maximum processor usage was 5% by armcc.
At meast 3GB of RAM available all the time while compilation worked, so about 5GB used by other apps.
Linking takes not more that 2 seconds.
Projects were the same, only other computers.
And a machine with SDD without TRIM support and heavily fragmented try defragmenting the SDD
Most defrag programs will not defrag a SSD, since they follow different rules when discussing fragmentation.
It costs quite little to have a file fragmented on a SSD since there is on head movement.
But it costs quite a lot to have the free space fragmented as small regions on many flash blocks.
And the file system layer doesn't know the mapping to flash blocks and so aren't able to properly defrag flash blocks.
Hence the need for TRIM support, where the OS reports unused or partially filled sectors in the file system to the flash controller - allowing the flash controller to understand what parts of flash blocks that is unused and then ahead of time rearrange used data to get completely unused flash blocks that can then be erased and ready for use. It makes a huge difference for the SSD to have pre-erased blocks when the OS needs to write data, instead of forcing the SSD to shuffle and rewrite static data just to get blocks to erase so the new writes can be performed.
My first guess would have been anti-virus software. The armcc.exe is run often and if it is checked every time it runs it is very significant (more than doubles the time to build). Very easy to have 2 different computers with different anti-virus settings. armcc.exe running only 5% of the time makes me wonder what else is going on. Make sure that you are showing CPU usage for all users and not just yourself.
Solved,
I've tested with Avast disabled, works like expected!
Thank you Robert!