Build times on Win 10


#1

Getting started with Argon in workbench. I notice that build times are very long. I understand why the initial build is long, but incrementals are very long, too. I’m on a very beefy machine with 10 physical cores so there’s really no shortage of power. Is there some way to speed this up? Ideally, an incremental build would only process the changed file and would do it very quickly.

Here’s what happens every time I build (and/or flash) in workbench:

> Executing task: make -f 'C:\Users\name\.particle\toolchains\buildscripts\1.2.0\Makefile' compile-user <

cd "C:/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1//main" && make all
make[1]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/main'
make -C ../modules/photon/user-part all
make[2]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/modules/photon/user-part'
make -C ../../../user
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/user'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/user'
make -C ../../../hal-dynalib
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/hal-dynalib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/hal-dynalib'
make -C ../../../services-dynalib
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/services-dynalib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/services-dynalib'
make -C ../../../system-dynalib
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/system-dynalib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/system-dynalib'
make -C ../../../rt-dynalib
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/rt-dynalib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/rt-dynalib'
make -C ../../../wiring
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/wiring'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/wiring'
make -C ../../../communication-dynalib
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/communication-dynalib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/communication-dynalib'
make -C ../../../platform
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/platform'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/platform'
make -C ../../../wiring_globals
make[3]: Entering directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/wiring_globals'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/wiring_globals'
C:/Users/name/.particle/toolchains/gcc-arm/5.3.1/bin/arm-none-eabi-size --format=berkeley c:/Users/name/Documents/Particle/projects/ArgonTest02/target/ArgonTest02.elf
   text    data     bss     dec     hex filename
   4716     112    1408    6236    185c c:/Users/name/Documents/Particle/projects/ArgonTest02/target/ArgonTest02.elf
make[2]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/modules/photon/user-part'
make[1]: Leaving directory '/cygdrive/c/Users/name/.particle/toolchains/deviceOS/1.0.1/firmware-1.0.1/main'

And each one of those make iterations takes several seconds. Any recommendations for how to speed this up?


#2

AFAIK the gcc-arm build process is single core.

Several seconds is pretty typical. I’ve used Workbench on Mac and Linux, and on Linux the build process takes under one second.

I don’t know how you would speed up your build times other than using Linux. If you really want build times under one second you definitely should.


#3

I have never had compile or build perf problems on Windows before now. Why would this particular tool chain and process be so slow on Windows but not on Linux? I mean, make is make, right? What am I missing?


#4

Okay, I timed it this morning. I was using “compile project” in vscode on a project that was already compiled. It took 32 (!!) seconds to do literally nothing. Just lots of “Entering directory” and “Nothing to be done” and “Leaving directory”. Surely this can’t be normal. This should take only a couple of seconds.

Is every Windows user here experiencing 30+ seconds as their minimum local build time for Particle projects?


#5

windows defender could be scanning the file as a test you could turn it off or any other firewall/virus scan tool you may have and see if the times improve. if they do then add the folder your file resides in to the exclusions list.


#6

With defender off the results don’t change.

I checked resource monitor and nothing (disk, memory or cpu) is getting pegged.

btw, this box has 64 GB of RAM and very fast SSDs. There really is no excuse for the terrible perf.

Are any of you running workbench on Windows? If so, can someone chime in to say whether you’re seeing similarly bad performance of builds?


#7

I think @rickkas7 might be able to chime in on this one, though you might have to wait until tomorrow. IIRC, he had a viable explanation for the difference between Windows and Linux.


#8

ok, i guess you need to try this,
go to windows update/security
select windows security
select virus and threat protection
look down at virus & threat protection settings
select manage settings
then turn off real-time protection

i guess you did not turn off virus scan but only firewall.
so try this.
and yes, i’m running on windows and doing this cut times from ~1min to 4-6 secs first run.


#9

That’s exactly what I did. It didn’t change build performance at all (at least not that I could measure using a timer).


#10

i’m out of ideas. someone else will get your issue resolved.


#11

Thanks. But I’m not sure there is really an issue yet. I mean, if everyone is seeing this same bad perf then there’s probably nothing I can fix on my end. Can anyone confirm that building an unchanged particle project on Windows should take considerably less than 32 seconds (in other words, someone is actually doing this on Windows and it’s working better for them)? If so then, good, I can grind away at the problem. If not then I’ll stop wasting everyone’s time here (and just complain to particle instead :slight_smile: )


#12

@gorsat, on my Win10x64 Dell i7 laptop I get 16 secs for a rebuild with a Xenon (0.9.0) target.


#13

Thanks @peekay123. So, presumably, my i9 workstation should do at least as well (assuming Argon doesn’t bring a heap more source complexity with it). Did you need to tweak any settings to improve build perf or are you using the out-of-the-box tool chain config?


#14

@gorsat, no tweaks, just regular install of VSC and Workbench. I have both Bitdefender and Windows Defender running with no exceptions. I compiled an application with 3 libraries with an Argon target with these timings after a “Clean application (local)”:

  • First compile (Compile application (local): 2min 30s
  • Second compile, no changes: 11.6s
  • Third compile, added comment in .ino file: 17.7s

#15

Hi,
I see cygdrive referenced in your logs, so I wonder: could it be that cygwin is messing things up?
I do not know if cygwin being there is normal for a Win install, but I have zero experience on it.

Otherwise, I would invoke the super powers of @m_m . Maybe he’s got some insights on this.


#16

Thanks. Yeah, I wondered about the cygdrive references. Is anyone else seeing these on Windows?


#17

hi all :wave:

our build times aren’t where we want them yet - sorry! we do install and run within a cygwin environment when running local compilation tasks on windows.

on my windows box, i see ~10m(!) for first run of the Particle: Compile application & DeviceOS (local) task, ~30s for the 2nd+ runs where we build incrementally.

on my mac box, i see ~4m 30s for first run, ~12s for 2nd+ runs.

on my linux (ubuntu) box, ~2m 30m for first run, 10s for 2nd+ runs.

in all cases, i’m compiling against Device OS v0.9.0 and targeting the argon platform with fairly trivial firmware (just blinking an LED).

so, based on this somewhat unscientific survey, i would say what you are seeing is expected.


#18

Ouch. So sad for us Windows folks. Fwiw, the last time I ran the Atmel tool chain (which was probably pretty similar in terms of functionality), it was pretty speedy on Windows, so maybe there are some tricks you can borrow for them?


#19

@m_m does Make not support multiple threads with the -j command? Would that not improve performance if more than 1 thread could be specified?


#20

alas, our current make system doesn’t support that as it is recursive