[SOLVED] Embedded Studio very slow on Windows, nine times faster in a virtual machine than on the native host

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Embedded Studio very slow on Windows, nine times faster in a virtual machine than on the native host

    After testing Segger Embedded Studio for the first time I thought it was unusually slow. Building the "blinky" example in the Nordic nRF5 SDK took 1 minute and 20 seconds on my Windows 10 computer at work.

    Out of curiosity I started up my Ubuntu virtual machine in VirtualBox, installed Embedded Studio, built exactly the same example, and it was nine times faster! A total of 9 seconds.

    Both installs use the same version of Embedded Studio (4.12) and the same hardware since one runs in a virtual machine on the other (Intel i7-4600U, 8 GB RAM).

    My host OS is Windows 10, the guest OS is Ubuntu 18.04. The source files and build target are all located on local storage.

    I'm a bit puzzled here, even if virtual machines are pretty fast these days, you would not expect the same program to run 9 times faster when virtualized compared to the native host.

    Does anyone have any pointers on where to start locating this issue? I would like to use Segger Embedded Studio for my future development but it is very annoying when it takes over a minute to build a simple example.

  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us. Most of my engineering colleagues use native Win7 or Win10 machines for building with Embedded Studio and it is extremely fast as you see on the VM.
    One thing that comes to mind is that the multi core detection is maybe not working quite right on the Windows machine.
    Do you have another PC to test against?
    Could you try setting the build threads manually?
    You can do so in the project explorer window in the top right corner (if it is now showing widen the window a bit more).
    There should be a drop down arrow where you can select building threads. Default is 0 which means automatic detection.
    Try to raise the number to e.g. 4 and see if the build speed improves on the Windows system.
    Does that improve the build speed?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Thank you for the reply, and thank you for actually reading and understanding my question. The response to questions in many forums (especially commercial support forums) seems to be cut-and-paste templates.

    Adjusting the number of threads did not help, the automatic detection seemed to figure out that 4 threads is a good number on this platform.

    I have been digging a little myself, and I remembered that I had some strange issues with git bash on the same computer. I found a thread where other people had speed problems with git bash, and for some crazy reason the problem was with their graphics driver: Git Bash (mintty) is extremely slow on Windows 10 OS


    Figuring it was worth a try and disabling my AMD driver, my build time went from 80 seconds to 19 seconds. I have absolutely no idea why, and upgrading to the latest AMD driver also fixed the build speed while using the AMD GPU.

    It is still not down to the same speed I get in the virtual machine, but I think I'll leave it here. It's now fast enough to work with.

  • Hello,

    Thank you for the flowers, we try our best to answer between software projects ;)

    Anders wrote:

    Figuring it was worth a try and disabling my AMD driver, my build time went from 80 seconds to 19 seconds. I have absolutely no idea why, and upgrading to the latest AMD driver also fixed the build speed while using the AMD GPU.
    This is a good hint. On my private PC I saw significant issues with my AMD card and Win10 in general. What basically happened is that Microsoft autoforces GPU driver updates on Win10 per default.
    This includes blatantly overwriting previously installed drivers by the user even if they were newer. This lead to all kinds of problems.
    My solution back then was to exclude automatic driver updates from the windows update service.
    That way only the driver version I intended to install was kept and I had no issues since.
    Maybe that helps in your case as well?
    This issue is known to Microsoft since 2016 but they have not done anything against it yet...

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.