Re: MSYS2 build slow
On Sun, May 31, 2020 at 12:41 PM Nathan Hartman wrote: > FWIW the build has become noticeably faster for me with latest master: > 1m21s now. Before, the build consistently took about 1m50s. So that's > 30 seconds saved. I build on Linux. I just wanted to follow up on this and say that apparently the build has become even faster recently. I'm not sure what has changed in the last few days, but it was a solid ~1m21s before and now it's down to about 1m2s. An additional almost 20 seconds saved with latest master... :-) Nathan
RE: MSYS2 build slow
Sorry for being so unresponsive, we had bank holidays and I've been away from my computer for 3 days. > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Not if CONFIG_HOST_WINDOWS=y in the defconfig file. That is what is set > in stm32f4discovery:nsh: > > $ grep -r CONFIG_HOST > boards/arm/stm32/stm32f4discovery/configs/nsh/defconfig > CONFIG_HOST_WINDOWS=y With a virgin clone of apache/incubator-nuttx, configure outputs the following in MSYS2: $ tools/configure.sh stm32f4discovery/nsh Copy files Select CONFIG_HOST_LINUX=y Refreshing... time make -j real4m48,811s user0m41,836s sys 1m47,151s make clean -j time make -j real3m23,974s user0m33,409s sys 1m34,379s If I force -g this gives the following results: $ tools/configure.sh -g stm32f4discovery/nsh Copy files Select CONFIG_HOST_WINDOWS=y Select CONFIG_WINDOWS_MSYS=y Refreshing... real3m47,740s user0m37,817s sys 1m44,749s make clean -j time make -j real3m26,775s user0m29,002s sys 1m17,780s Overall I see some fluctuation (build time can be sometimes as well in the 7-8min range), but this seems to be related to my system. So for me there's one question left: Why seems Greg's CYGWIN to be faster than my MSYS2. But since I can again achieve build times in the 3 to 4min range, that's not of much importance. (Nevertheless I will try WSL someday.) Johannes
Re: MSYS2 build slow
Build performance has not been a priority for us yet. Johannes' 30 minute build rocked us into some stopgap action. If and when it becomes a priority there is probably more we can do in the future.Sent from Samsung tablet. Original message From: Nathan Hartman Date: 5/31/20 10:46 AM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: MSYS2 build slow On Sun, May 31, 2020 at 12:44 PM Gregory Nutt wrote:>> > FWIW the build has become noticeably faster for me with latest master:> > 1m21s now. Before, the build consistently took about 1m50s. So that's> > 30 seconds saved. I build on Linux.> yes I have seen improvements of 25-30% on all platforms, and more on> some Window's platforms that are more sensitive to forking shells. That> should make a really bit difference if you are building several hundred> configurations.>That's fantastic! I'm sure everyone will appreciate faster builds!Nathan
Re: MSYS2 build slow
On Sun, May 31, 2020 at 12:44 PM Gregory Nutt wrote: > > > FWIW the build has become noticeably faster for me with latest master: > > 1m21s now. Before, the build consistently took about 1m50s. So that's > > 30 seconds saved. I build on Linux. > yes I have seen improvements of 25-30% on all platforms, and more on > some Window's platforms that are more sensitive to forking shells. That > should make a really bit difference if you are building several hundred > configurations. > That's fantastic! I'm sure everyone will appreciate faster builds! Nathan
Re: MSYS2 build slow
FWIW the build has become noticeably faster for me with latest master: 1m21s now. Before, the build consistently took about 1m50s. So that's 30 seconds saved. I build on Linux. yes I have seen improvements of 25-30% on all platforms, and more on some Window's platforms that are more sensitive to forking shells. That should make a really bit difference if you are building several hundred configurations.
Re: MSYS2 build slow
On Wed, May 27, 2020 at 8:06 PM Nathan Hartman wrote: > I build on Linux and those build times seem fast to me (20-30 seconds, 45-60 > seconds). I don't know if I've ever had builds that fast, but it might be my > configurations, or my machine. I'll build one now... > > Latest master: 1m 47s FWIW the build has become noticeably faster for me with latest master: 1m21s now. Before, the build consistently took about 1m50s. So that's 30 seconds saved. I build on Linux. Cheers, Nathan
Re: MSYS2 build slow
There is no issue in reporting complaints here. :) The changes to Make.defs do also improve performance, however we need to do some hacks to get rid of the error messages. On Sun, May 31, 2020 at 1:16 PM Maciej Wójcik wrote: Thanks for explanation. I went through that PR right now. I was just reporting as a good citizen :) I will check Issue pane next time before spamming. PR 1152 fixes those cosmetic error complaints. It is finally complete and reviewed (more review is always good). Hopefully, it will be merged to master once it completes its PR checks. The PR got a major revision this morning. We had it mostly working last night but that approach required to many band-aids and needed a sweeping rethink. If you are interested you should look again.
Re: MSYS2 build slow
There is no issue in reporting complaints here. :) The changes to Make.defs do also improve performance, however we need to do some hacks to get rid of the error messages. On Sun, May 31, 2020 at 1:16 PM Maciej Wójcik wrote: > > Thanks for explanation. I went through that PR right now. > > I was just reporting as a good citizen :) I will check Issue pane next time > before spamming.
Re: MSYS2 build slow
Thanks for explanation. I went through that PR right now. I was just reporting as a good citizen :) I will check Issue pane next time before spamming.
Re: MSYS2 build slow
Note that the error messages do not come from incorporating incdir.c into the build system but rather from using immediate variables in Make.defs On Sun, May 31, 2020 at 1:47 PM Abdelatif Guettouche wrote: > > > When I simply clone > > and configure NuttX, I get a repeated error. > > Yes, we are aware of those and actually have a solution (in > https://github.com/apache/incubator-nuttx/pull/1152) > However, we are still discussing other alternatives (or even reverting > the changes) > Sorry for the inconvenience. > > > On Sun, May 31, 2020 at 12:42 PM Maciej Wójcik wrote: > > > > > > > > PR 1149 has been merged. That means that the incdir.c program has now > > > been incorporated into the build system. > > > > > > There might be some regression within this solution. When I simply clone > > and configure NuttX, I get a repeated error. It might be related to recent > > change > > > > mkdir test > > cd test > > git clone https://bitbucket.org/nuttx/nuttx.git > > git clone https://bitbucket.org/nuttx/apps.git > > cd nuttx > > $ ./tools/configure.sh stm32f4discovery:nsh > > Copy files > > Select CONFIG_HOST_LINUX=y > > Refreshing... > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > > > > > > > Am Sa., 30. Mai 2020 um 04:25 Uhr schrieb Gregory Nutt > >: > > > > > Johannes, > > > > > > PR 1149 has been merged. That means that the incdir.c program has now > > > been incorporated into the build system. It all checks out: I have > > > pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho > > > de Assis have checked it out well on Linux. The PR also passes all of > > > the PR build checks which verifies that it works correctly with Linux > > > and macOS. > > > > > > The only untested platform is MSYS and there could very well be issues > > > there. I have MSYS2 installed on two systems. I tried testing on my > > > laptop tonight but there is something screwed up in the MSYS2 > > > installation. I have both MSYS2 and Cygwin installed and I am thinking > > > that when I build with Cygwin , it messes up the MSYS2 configuration > > > (and vice versa). They share the same repository files. I am not sure > > > what is going on but I was not able to verify on MSYS2. I will try > > > again on my desktop in the morning. > > > > > > If you find problems, you can be pretty much assured that the problem is > > > in tools/incdir.c and I will work with you to resolve any issues that > > > you run across. If you do have problems, try using 'make V=1'. That > > > will show us the arguments to and the output from incdir.exe. > > > > > > Greg > > > > > >
Re: MSYS2 build slow
> When I simply clone > and configure NuttX, I get a repeated error. Yes, we are aware of those and actually have a solution (in https://github.com/apache/incubator-nuttx/pull/1152) However, we are still discussing other alternatives (or even reverting the changes) Sorry for the inconvenience. On Sun, May 31, 2020 at 12:42 PM Maciej Wójcik wrote: > > > > > PR 1149 has been merged. That means that the incdir.c program has now > > been incorporated into the build system. > > > There might be some regression within this solution. When I simply clone > and configure NuttX, I get a repeated error. It might be related to recent > change > > mkdir test > cd test > git clone https://bitbucket.org/nuttx/nuttx.git > git clone https://bitbucket.org/nuttx/apps.git > cd nuttx > $ ./tools/configure.sh stm32f4discovery:nsh > Copy files > Select CONFIG_HOST_LINUX=y > Refreshing... > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found > > > > Am Sa., 30. Mai 2020 um 04:25 Uhr schrieb Gregory Nutt >: > > > Johannes, > > > > PR 1149 has been merged. That means that the incdir.c program has now > > been incorporated into the build system. It all checks out: I have > > pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho > > de Assis have checked it out well on Linux. The PR also passes all of > > the PR build checks which verifies that it works correctly with Linux > > and macOS. > > > > The only untested platform is MSYS and there could very well be issues > > there. I have MSYS2 installed on two systems. I tried testing on my > > laptop tonight but there is something screwed up in the MSYS2 > > installation. I have both MSYS2 and Cygwin installed and I am thinking > > that when I build with Cygwin , it messes up the MSYS2 configuration > > (and vice versa). They share the same repository files. I am not sure > > what is going on but I was not able to verify on MSYS2. I will try > > again on my desktop in the morning. > > > > If you find problems, you can be pretty much assured that the problem is > > in tools/incdir.c and I will work with you to resolve any issues that > > you run across. If you do have problems, try using 'make V=1'. That > > will show us the arguments to and the output from incdir.exe. > > > > Greg > > > >
Re: MSYS2 build slow
> > PR 1149 has been merged. That means that the incdir.c program has now > been incorporated into the build system. There might be some regression within this solution. When I simply clone and configure NuttX, I get a repeated error. It might be related to recent change mkdir test cd test git clone https://bitbucket.org/nuttx/nuttx.git git clone https://bitbucket.org/nuttx/apps.git cd nuttx $ ./tools/configure.sh stm32f4discovery:nsh Copy files Select CONFIG_HOST_LINUX=y Refreshing... /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found /bin/sh: 1: /home/user/tmp/test/nuttx/tools/incdir: not found Am Sa., 30. Mai 2020 um 04:25 Uhr schrieb Gregory Nutt : > Johannes, > > PR 1149 has been merged. That means that the incdir.c program has now > been incorporated into the build system. It all checks out: I have > pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho > de Assis have checked it out well on Linux. The PR also passes all of > the PR build checks which verifies that it works correctly with Linux > and macOS. > > The only untested platform is MSYS and there could very well be issues > there. I have MSYS2 installed on two systems. I tried testing on my > laptop tonight but there is something screwed up in the MSYS2 > installation. I have both MSYS2 and Cygwin installed and I am thinking > that when I build with Cygwin , it messes up the MSYS2 configuration > (and vice versa). They share the same repository files. I am not sure > what is going on but I was not able to verify on MSYS2. I will try > again on my desktop in the morning. > > If you find problems, you can be pretty much assured that the problem is > in tools/incdir.c and I will work with you to resolve any issues that > you run across. If you do have problems, try using 'make V=1'. That > will show us the arguments to and the output from incdir.exe. > > Greg > >
Re: MSYS2 build slow
Without specifying -g CONFIG_HOST_LINUX is assumed.
This worked well in the past with MSYS2.
But I will try -g later today.
Not if CONFIG_HOST_WINDOWS=y in the defconfig file. That is what is set
in stm32f4discovery:nsh:
$ grep -r CONFIG_HOST
boards/arm/stm32/stm32f4discovery/configs/nsh/defconfig
CONFIG_HOST_WINDOWS=y
I also double checked Xiang's recommendation using this patch:
$ diff -u boards/arm/stm32/stm32f4discovery/scripts/Make.defs .
--- boards/arm/stm32/stm32f4discovery/scripts/Make.defs 2020-05-26
07:39:23.201472900 -0600
+++ ./Make.defs 2020-05-30 08:34:55.802400700 -0600
@@ -39,10 +39,11 @@
LDSCRIPT = ld.script
-ARCHINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
+CINCPATH := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
+CXXINCPATH := ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
-ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include}
-ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
+ARCHINCLUDES += $(CINCPATH)
+ARCHXXINCLUDES += $(CINCPATH) $(CXXINCPATH)
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
ARCHSCRIPT = -T "${shell cygpath -w
$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
That also gives a smaller, but consistent improvement in build time:
BEFORE:
time make
real 3m35.242s
user 0m26.620s
sys 1m9.932s
time make -j
real 0m47.548s
user 0m30.717s
sys 1m45.736s
AFTER:
time make
real 3m14.522s
user 0m21.474s
sys 0m56.380s
time make -j
real 0m46.532s
user 0m24.673s
sys 1m24.048s
Again, that is using Cygwin on 32Gb Rizen 5 3600
Greg
RE: MSYS2 build slow
Without specifying -g CONFIG_HOST_LINUX is assumed. This worked well in the past with MSYS2. But I will try -g later today. Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > > For MSYS2 on my i7-3770 it's (every tests with jobs enabled): > > # make distclean > > # tools/configure.sh stm32f4discovery/nsh > You really should specific -g on the configure.sh command line. > Otherwise, the system will assume you are building for Cygwin. There are > only a few differences between Cygwin and MSYS2, but though you should > know.
Re: MSYS2 build slow
For MSYS2 on my i7-3770 it's (every tests with jobs enabled): # make distclean # tools/configure.sh stm32f4discovery/nsh You really should specific -g on the configure.sh command line. Otherwise, the system will assume you are building for Cygwin. There are only a few differences between Cygwin and MSYS2, but though you should know.
RE: MSYS2 build slow
For MSYS2 on my i7-3770 it's (every tests with jobs enabled): # make distclean # tools/configure.sh stm32f4discovery/nsh # time make -j real6m24,970s user1m5,615s sys 3m18,369s # make clean -j # time make -j real4m26,780s user0m58,376s sys 2m54,523s For comparison I checked out one commit before the "-I to INCDIR" change: #git checkout 23668a4b9b3c15c7367ff21befb4a6f48d01ffb7 # make distclean # tools/configure.sh stm32f4discovery/nsh # time make -j real3m52,370s user0m40,846s sys 2m1,092s # make clean -j # time make -j real3m0,449s user0m34,298s sys 1m39,438s What is interesting: With the change to incdir.c portions of the build process are still slower than before the "-I to INCDIR" change, but other portions are faster (libdrivers,libboard). It would be interesting if someone could verify my results (or am I the only MSYS2 user?). Overall it's still slower than before, but it's back in the ballpark. Thanks. Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Saturday, May 30, 2020 4:25 AM > To: dev@nuttx.apache.org > Subject: Re: MSYS2 build slow > > Johannes, > > PR 1149 has been merged. That means that the incdir.c program has now > been incorporated into the build system. It all checks out: I have > pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho > de Assis have checked it out well on Linux. The PR also passes all of > the PR build checks which verifies that it works correctly with Linux > and macOS. > > The only untested platform is MSYS and there could very well be issues > there. I have MSYS2 installed on two systems. I tried testing on my > laptop tonight but there is something screwed up in the MSYS2 > installation. I have both MSYS2 and Cygwin installed and I am thinking > that when I build with Cygwin , it messes up the MSYS2 configuration > (and vice versa). They share the same repository files. I am not sure > what is going on but I was not able to verify on MSYS2. I will try > again on my desktop in the morning. > > If you find problems, you can be pretty much assured that the problem is > in tools/incdir.c and I will work with you to resolve any issues that > you run across. If you do have problems, try using 'make V=1'. That > will show us the arguments to and the output from incdir.exe. > > Greg
Re: MSYS2 build slow
Johannes, PR 1149 has been merged. That means that the incdir.c program has now been incorporated into the build system. It all checks out: I have pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho de Assis have checked it out well on Linux. The PR also passes all of the PR build checks which verifies that it works correctly with Linux and macOS. The only untested platform is MSYS and there could very well be issues there. I have MSYS2 installed on two systems. I tried testing on my laptop tonight but there is something screwed up in the MSYS2 installation. I have both MSYS2 and Cygwin installed and I am thinking that when I build with Cygwin , it messes up the MSYS2 configuration (and vice versa). They share the same repository files. I am not sure what is going on but I was not able to verify on MSYS2. I will try again on my desktop in the morning. If you find problems, you can be pretty much assured that the problem is in tools/incdir.c and I will work with you to resolve any issues that you run across. If you do have problems, try using 'make V=1'. That will show us the arguments to and the output from incdir.exe. Greg
Re: MSYS2 build slow
As a comparison I did: - make clean - make The dependencies only have to be recreated on the first build, not on subsequent builds. In that case I get 3 minutes and 30 seconds. So the Cygwin dependency generation vi mkwindeps.sh requires about 2 minutes by itself But with the current changes I get: $ make clean $ time make -j real 0m46.981s user 0m28.503s sys 1m42.016s That is the fastest Cygwin build I have EVER done!
Re: MSYS2 build slow
I am most of the way through converting incdir.sh to a C version, incdir.c. I will probably submit a PR that just adds the .c file (without changing the build system). Then we can experiment with it and make sure we are comfortable before bringing it into the build. I will first test with Cygwin where I was seeing 7 minutes (still too long). I won't bother if there is no significant improvement. Okay.. I have submitted the C version of incdir.sh and it is a lot faster. That is PR 1148. Please do review. I using Cygwin which did not have the terrible performance as you are seeing under MSYS2. I but I still got a substantial improvement, from 7 minutes down to 5 minutes and 20 seconds. That is 75% from the previous time. I bet you do a lot better than that. I believe it should be even faster than it was before (not forks at all!). The new .c file is NOT yet hooked into the build system. There are special instructions available in the PR 1148 comments under the Testing section. Essentially, you override the definition of INCDIR as incdir.sh changing it to be incdir.exe (and, of course, you have to build incdir.exe manually). One thing I noted when I measured that 5 min 20 sec build time is that a large part of the time is spent making dependencies. For Linux, that uses the mkdeps.c version, but for Cywgin, it uses the script mkwindeps.sh. As a comparison I did: - make clean - make The dependencies only have to be recreated on the first build, not on subsequent builds. In that case I get 3 minutes and 30 seconds. So the Cygwin dependency generation vi mkwindeps.sh requires about 2 minutes by itself.
Re: MSYS2 build slow
I must admit I thought about that idea also, but I wasn't sure about the portability issue. You could also think about a autogenerated Make.defs during configure with then hard coded include paths which should be the fastest possibility. Since Make.defs is already copied, perhaps it could also be modified on the fly. I am most of the way through converting incdir.sh to a C version, incdir.c. I will probably submit a PR that just adds the .c file (without changing the build system). Then we can experiment with it and make sure we are comfortable before bringing it into the build. I will first test with Cygwin where I was seeing 7 minutes (still too long). I won't bother if there is no significant improvement. Okay.. I have submitted the C version of incdir.sh and it is a lot faster. That is PR 1148. Please do review. I using Cygwin which did not have the terrible performance as you are seeing under MSYS2. I but I still got a substantial improvement, from 7 minutes down to 5 minutes and 20 seconds. That is 75% from the previous time. I bet you do a lot better than that. I believe it should be even faster than it was before (not forks at all!). The new .c file is NOT yet hooked into the build system. There are special instructions available in the PR 1148 comments under the Testing section. Essentially, you override the definition of INCDIR as incdir.sh changing it to be incdir.exe (and, of course, you have to build incdir.exe manually).
Re: MSYS2 build slow
I must admit I thought about that idea also, but I wasn't sure about the portability issue. You could also think about a autogenerated Make.defs during configure with then hard coded include paths which should be the fastest possibility. Since Make.defs is already copied, perhaps it could also be modified on the fly. I am most of the way through converting incdir.sh to a C version, incdir.c. I will probably submit a PR that just adds the .c file (without changing the build system). Then we can experiment with it and make sure we are comfortable before bringing it into the build. I will first test with Cygwin where I was seeing 7 minutes (still too long). I won't bother if there is no significant improvement.
RE: MSYS2 build slow
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Could you try the method I said before? Immediate make variable could
> avoid invoke the shell script at every reference location which is some form
> of cache inside make instead of incdir.sh.
It's
real22m50,526s
user1m37,024s
sys 4m25,220s
with
ARCHINCLUDES := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
in nuttx/Make.defs.
So it's faster (23min < 36min) but still far away from 4-5min it used to be.
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Another, probably better solution, would be to re-write incdir.sh in C.
I must admit I thought about that idea also, but I wasn't sure about the
portability issue.
You could also think about a autogenerated Make.defs during configure with then
hard coded include paths which should be the fastest possibility.
Since Make.defs is already copied, perhaps it could also be modified on the fly.
Johannes
Re: MSYS2 build slow
Isn't there a possibility to cache the results of the system checks
inside incdir.sh?
The cost of getting 'os' is fork + new shell + uname
The cost of gcc is fork + new shell + grep
The cost of exfile if for + new shell + basename
Yes, so that does have to fork a lot of additional shell instances.
Perhaps you could use environment variables to cache results. I
think that Bash can access environment variables without forking.
For example, I think that you replace the line:
os=`uname -o 2>/dev/null || echo "Other"`
with
|if[-z ${os+x}];then|
export os=`uname -o 2>/dev/null || echo "Other"`
fi
See discussion of syntax at
https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash
We could probably greatly improve build performance if this were done
throughout the OS. An alternative might be to set a large set of
environment variables as part of the 'make context' phase.
In either case, we would also have to unset the environment variables
on distclean as well.
Another, probably better solution, would be to re-write incdir.sh in C.
Then it would not require a fork to bet to uname() or basename(). Host
C is supported on all platforms and would not require additional build
tools (as would, say, Python or other scripting language). C is also
portable and can work in all POSIX environments and Windows native
environments.
There are C versions of several .sh files under tools now, so it is not
a radical idea.
And actually it would not be too difficult to do. I could even do that
if you agree to that solution.
Re: MSYS2 build slow
By hardcoding
os=Msys
gcc=arm-none-eabi-gcc
exefile=arm-none-eabi-gcc
inside incdir.sh
time tools/incdir.sh -s
arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include
reduced from 180ms to 40ms.
Overall, this reduced build time from 30min to an acceptable 6min.
So incdir.sh is taking too much time in MSYS2
Isn't there a possibility to cache the results of the system checks
inside incdir.sh?
The cost of getting 'os' is fork + new shell + uname
The cost of gcc is fork + new shell + grep
The cost of exfile if for + new shell + basename
Yes, so that does have to fork a lot of additional shell instances.
Perhaps you could use environment variables to cache results. I
think that Bash can access environment variables without forking.
For example, I think that you replace the line:
os=`uname -o 2>/dev/null || echo "Other"`
with
|if[-z ${os+x}];then|
export os=`uname -o 2>/dev/null || echo "Other"`
fi
See discussion of syntax at
https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash
We could probably greatly improve build performance if this were done
throughout the OS. An alternative might be to set a large set of
environment variables as part of the 'make context' phase.
In either case, we would also have to unset the environment variables on
distclean as well.
Re: MSYS2 build slow
By hardcoding
os=Msys
gcc=arm-none-eabi-gcc
exefile=arm-none-eabi-gcc
inside incdir.sh
time tools/incdir.sh -s
arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include
reduced from 180ms to 40ms.
Overall, this reduced build time from 30min to an acceptable 6min.
So incdir.sh is taking too much time in MSYS2
Isn't there a possibility to cache the results of the system checks
inside incdir.sh?
The cost of getting 'os' is fork + new shell + uname
The cost of gcc is fork + new shell + grep
The cost of exfile if for + new shell + basename
Yes, so that does have to fork a lot of additional shell instances.
Perhaps you could use environment variables to cache results. I think
that Bash can access environment variables without forking.
For example, I think that you replace the line:
os=`uname -o 2>/dev/null || echo "Other"`
with
|if[-z ${os+x}];then|
export os=`uname -o 2>/dev/null || echo "Other"`
fi
See discussion of syntax at
https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash
Re: MSYS2 build slow
By hardcoding os=Msys gcc=arm-none-eabi-gcc exefile=arm-none-eabi-gcc inside incdir.sh time tools/incdir.sh -s arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include reduced from 180ms to 40ms. Overall, this reduced build time from 30min to an acceptable 6min. So incdir.sh is taking too much time in MSYS2 Isn't there a possibility to cache the results of the system checks inside incdir.sh? The cost of getting 'os' is fork + new shell + uname The cost of gcc is fork + new shell + grep The cost of exfile if for + new shell + basename Yes, so that does have to fork a lot of additional shell instances. Perhaps you could use environment variables to cache results. I think that Bash can access environment variables without forking.
RE: MSYS2 build slow
My time on WSL: real0m0.014s user0m0.014s sys 0m0.001s The cost most likely come from the creation of new shell process even you empty the shell script I think there isn't much difference. Could you try the method I said before? Immediate make variable could avoid invoke the shell script at every reference location which is some form of cache inside make instead of incdir.sh. > -Original Message- > From: Gregory Nutt > Sent: Friday, May 29, 2020 10:11 PM > To: dev@nuttx.apache.org > Subject: Re: MSYS2 build slow > > > > Would please someone do the following command on Linux and Cygwin? > > > > time tools/incdir.sh -s arm-none-eabi-gcc > > /home/Schock/nuttx/nuttx/include > > > > (Replace the path with your NuttX path.) > > > > For MSYS2 it's in the range of: > > > > real0m0,189s > > user0m0,061s > > sys 0m0,045s > > > I don't have the Linux box on now, but here are the results on Cygwin (32Gb > Rizen 5 3600, NVMe): > > First time: > > $ time tools/incdir.sh -s arm-none-eabi-gcc > /home/Schock/nuttx/nuttx/include > -isystem "/home/Schock/nuttx/nuttx/include" > > real0m0.198s > user0m0.000s > sys 0m0.092s > > Thereafter: > > real0m0.094s > user0m0.000s > sys 0m0.075s > > After incdir.sh has been included in the in-memory cache, it is pretty fast. > But it can never be super fast. Both Cygwin and MSYS2 > suffer from the well documented fork problem: > https://superuser.com/questions/133313/can-i-speed-up-cygwins-fork . So that > is what causes the ports of GNU tools to be so slow > in Cygwin. Anti-virus run time checking is a big factor too. >
Re: MSYS2 build slow
Would please someone do the following command on Linux and Cygwin? time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include (Replace the path with your NuttX path.) For MSYS2 it's in the range of: real0m0,189s user0m0,061s sys 0m0,045s I don't have the Linux box on now, but here are the results on Cygwin (32Gb Rizen 5 3600, NVMe): First time: $ time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include -isystem "/home/Schock/nuttx/nuttx/include" real 0m0.198s user 0m0.000s sys 0m0.092s Thereafter: real 0m0.094s user 0m0.000s sys 0m0.075s After incdir.sh has been included in the in-memory cache, it is pretty fast. But it can never be super fast. Both Cygwin and MSYS2 suffer from the well documented fork problem: https://superuser.com/questions/133313/can-i-speed-up-cygwins-fork . So that is what causes the ports of GNU tools to be so slow in Cygwin. Anti-virus run time checking is a big factor too.
RE: MSYS2 build slow
By hardcoding os=Msys gcc=arm-none-eabi-gcc exefile=arm-none-eabi-gcc inside incdir.sh time tools/incdir.sh -s arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include reduced from 180ms to 40ms. Overall, this reduced build time from 30min to an acceptable 6min. So incdir.sh is taking too much time in MSYS2 Isn't there a possibility to cache the results of the system checks inside incdir.sh? Regards, Johannes > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Friday, May 29, 2020 3:14 PM > To: dev@nuttx.apache.org > Subject: RE: MSYS2 build slow > > Would please someone do the following command on Linux and Cygwin? > > time tools/incdir.sh -s arm-none-eabi-gcc > /home/Schock/nuttx/nuttx/include > > (Replace the path with your NuttX path.) > > For MSYS2 it's in the range of: > > real0m0,189s > user0m0,061s > sys 0m0,045s > > Thanks, Johannes > > > From: Gregory Nutt [mailto:spudan...@gmail.com] > > Okay, so only MSYS2 is seeing a dramatic change. That is a mystery.
Re: MSYS2 build slow
For me it looks as below (in windows, cygwin environment). $ time tools/incdir.sh -s arm-none-eabi-gcc ./include -isystem "./include" real0m0.342s user0m0.046s sys 0m0.261s With best regards, Phani. On Fri, May 29, 2020 at 6:43 PM Schock, Johannes - NIVUS GmbH < johannes.sch...@nivus.com> wrote: > Would please someone do the following command on Linux and Cygwin? > > time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include > > (Replace the path with your NuttX path.) > > For MSYS2 it's in the range of: > > real0m0,189s > user0m0,061s > sys 0m0,045s > > Thanks, Johannes > > > From: Gregory Nutt [mailto:spudan...@gmail.com] > > Okay, so only MSYS2 is seeing a dramatic change. That is a mystery. >
RE: MSYS2 build slow
Would please someone do the following command on Linux and Cygwin? time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include (Replace the path with your NuttX path.) For MSYS2 it's in the range of: real0m0,189s user0m0,061s sys 0m0,045s Thanks, Johannes > From: Gregory Nutt [mailto:spudan...@gmail.com] > Okay, so only MSYS2 is seeing a dramatic change. That is a mystery.
Re: MSYS2 build slow
On Wed, May 27, 2020 at 3:39 PM Gregory Nutt wrote: > > >> it seems because ARCHINCLUDES try to figure out the search path by > >> invoking shell script: > > > > But wouldn't that affect all platforms proportionally? Why would that > > cause such a huge increase on MSYS2. > > > > I saw a 7 minute build time on Cygwin. That is also very high, but > > not at all the kind of time increase that Johannes is seeing. I was > > building on Cygwin at about 3 minutes at some time in the past, so the > > build time has increases significantly for me too. > > > > On Cygwin, I have always noticed that the build rate would slow down > > when it got the to the drivers/ directory. It would slow by a factor > > of 2-3X. This, we disccovered, as do to all of the include paths that > > had to be searched. When you build the drivrs/, there can be many > > include paths that really slows down the build. > > > > Could something like that be happening here too? > > I have seen a slow-down in builds under Linux as well. But since the > Linux builds are already so fast it is less evident. Before i was > building at around 20-30 seconds per build; now it is are 45-60 seconds > per build. > > Has anyone else seen this? I build on Linux and those build times seem fast to me (20-30 seconds, 45-60 seconds). I don't know if I've ever had builds that fast, but it might be my configurations, or my machine. I'll build one now... Latest master: 1m 47s Let me get an older revision... 1m 50s to build with bb10e0fc25a1c6006e8ad2724be29173d4858494 which is before the commit mentioned by the OP. These build times are pretty consistent with what they've always been for me, approximately 2 minutes for a complete build. So, at least so far, I don't see a change... Nathan
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too? I have seen a slow-down in builds under Linux as well. But since the Linux builds are already so fast it is less evident. Before i was building at around 20-30 seconds per build; now it is are 45-60 seconds per build. Has anyone else seen this? I should clarify... that is using testbuild.sh so it includes make disclean and configure.sh times too. The actual build time is somewhat less than that.
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too? I have seen a slow-down in builds under Linux as well. But since the Linux builds are already so fast it is less evident. Before i was building at around 20-30 seconds per build; now it is are 45-60 seconds per build. Has anyone else seen this?
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by invoking shell script: But wouldn't that affect all platforms proportionally? Why would that cause such a huge increase on MSYS2. I saw a 7 minute build time on Cygwin. That is also very high, but not at all the kind of time increase that Johannes is seeing. I was building on Cygwin at about 3 minutes at some time in the past, so the build time has increases significantly for me too. On Cygwin, I have always noticed that the build rate would slow down when it got the to the drivers/ directory. It would slow by a factor of 2-3X. This, we disccovered, as do to all of the include paths that had to be searched. When you build the drivrs/, there can be many include paths that really slows down the build. Could something like that be happening here too?
Re: MSYS2 build slow
Hi Johannes, Did you try to reverse this commit to see if the problem goes away? BR, Alan On 5/27/20, Schock, Johannes - NIVUS GmbH wrote: > If I have done everything right with usage of git bisect, the below commit > increased build time by factor 7 for MSYS2. > Since this is a rather huge commit, I think I can't be helpful figuring out > the actual reason. > And I'm not sure if this is perhaps even considered acceptable. > > Regards, Johannes > > $ git bisect bad > 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit > commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 > Author: Xiang Xiao > Date: Tue May 19 17:43:29 2020 +0800 > > build: Replace -I with INCDIR > >> -Original Message- >> From: Schock, Johannes - NIVUS GmbH >> [mailto:johannes.sch...@nivus.com] >> Sent: Wednesday, May 27, 2020 10:45 AM >> To: dev@nuttx.apache.org >> Subject: MSYS2 build slow >> >> Just as an intermediate result: >> MSYS2 >> >> make distclean >> tools/configure.sh stm32f4discovery/nsh >> time make >> >> current master >> real35m54,957s >> user2m29,879s >> sys 6m31,525s >> >> releases/9.0 >> real4m39,324s >> user0m28,553s >> sys 1m23,113s >> >> The build is much slower than it used to be. >> Does someone have an idea which commit could have caused this? >> I will start a bisect later today. (Never did before, let's see.) >> >> Johannes >
Re: MSYS2 build slow
it seems because ARCHINCLUDES try to figure out the search path by
invoking shell script:
diff --git a/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
b/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
index 35cdb5ab6a..f60d2d9e31 100644
--- a/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
+++ b/boards/arm/stm32/stm32f4discovery/configs/cxxtest/Make.defs
@@ -55,19 +55,16 @@ LIBSUPXX = ${shell $(CC) $(CXXFLAGS)
--print-file-name=libsupc++.a}
EXTRA_LIBPATHS = -L "${shell dirname "$(LIBSUPXX)"}"
EXTRA_LIBS = -lsupc++
+ARCHINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
+
+ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
+ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
+ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)uClibc++}
+
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
- # Windows-native toolchains
- ARCHINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
- ARCHXXINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}" \
--isystem "${shell cygpath -w $(TOPDIR)/include/cxx}" \
--isystem "${shell cygpath -w $(TOPDIR)/include/uClibc++}"
- ARCHSCRIPT = -T "${shell cygpath -w
$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)}"
+ ARCHSCRIPT = -T "${shell cygpath -w
$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
else
- # Linux/Cygwin-native toolchain
- ARCHINCLUDES = -I. -isystem $(TOPDIR)/include
- ARCHXXINCLUDES = -I. -isystem $(TOPDIR)/include \
--isystem $(TOPDIR)/include/cxx -isystem $(TOPDIR)/include/uClibc++
- ARCHSCRIPT =
-T$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)
+ ARCHSCRIPT =
-T$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)$(CONFIG_ARCH_BOARD)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
endif
ARCHXXINCLUDES is a deferred variable which mean the script will
exeutable in every reference. Could you try this:
ARCHXXINCLUDES := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)uClibc++}
https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html
On Wed, May 27, 2020 at 9:26 PM Schock, Johannes - NIVUS GmbH
wrote:
>
> If I have done everything right with usage of git bisect, the below commit
> increased build time by factor 7 for MSYS2.
> Since this is a rather huge commit, I think I can't be helpful figuring out
> the actual reason.
> And I'm not sure if this is perhaps even considered acceptable.
>
> Regards, Johannes
>
> $ git bisect bad
> 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit
> commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0
> Author: Xiang Xiao
> Date: Tue May 19 17:43:29 2020 +0800
>
> build: Replace -I with INCDIR
>
> > -Original Message-
> > From: Schock, Johannes - NIVUS GmbH
> > [mailto:johannes.sch...@nivus.com]
> > Sent: Wednesday, May 27, 2020 10:45 AM
> > To: dev@nuttx.apache.org
> > Subject: MSYS2 build slow
> >
> > Just as an intermediate result:
> > MSYS2
> >
> > make distclean
> > tools/configure.sh stm32f4discovery/nsh
> > time make
> >
> > current master
> > real35m54,957s
> > user2m29,879s
> > sys 6m31,525s
> >
> > releases/9.0
> > real4m39,324s
> > user0m28,553s
> > sys 1m23,113s
> >
> > The build is much slower than it used to be.
> > Does someone have an idea which commit could have caused this?
> > I will start a bisect later today. (Never did before, let's see.)
> >
> > Johannes
RE: MSYS2 build slow
If I have done everything right with usage of git bisect, the below commit increased build time by factor 7 for MSYS2. Since this is a rather huge commit, I think I can't be helpful figuring out the actual reason. And I'm not sure if this is perhaps even considered acceptable. Regards, Johannes $ git bisect bad 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 Author: Xiang Xiao Date: Tue May 19 17:43:29 2020 +0800 build: Replace -I with INCDIR > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Wednesday, May 27, 2020 10:45 AM > To: dev@nuttx.apache.org > Subject: MSYS2 build slow > > Just as an intermediate result: > MSYS2 > > make distclean > tools/configure.sh stm32f4discovery/nsh > time make > > current master > real35m54,957s > user2m29,879s > sys 6m31,525s > > releases/9.0 > real4m39,324s > user0m28,553s > sys 1m23,113s > > The build is much slower than it used to be. > Does someone have an idea which commit could have caused this? > I will start a bisect later today. (Never did before, let's see.) > > Johannes
