I've narrowed this Windows build performance regression down to the original branches/gbuild commits 1409589 and 1409590, which go together and can't be split up.
* r1409589: gnumake4: #i117845#: LinkTarget.mk: fix dep-files for GenCxxObjects: pass the dep-file target explicitly as a parameter to the Object__commands. * r1409590: gnumake4: #i117845#: LinkTarget.mk: refactor dep-files: introduce dependency from object dep-file to object. The make rules involved are complex and affect all platforms. Proceeding further is a real PITA :-(. On Fri, Jul 22, 2016 at 7:05 PM, Damjan Jovanovic <dam...@apache.org> wrote: > The Windows build performance regression first occurs in r1735004, which > takes 676 minutes to build compared to 330 minutes in the commit just > before it. Only wall clock time increases, "user" and "system" times remain > the same. > > 4 patches from branches/gbuild were merged in that commit. 3 of them are > rather complex and none jump out at me, so I'll have to do more splitting > up and building to find the one responsible. > > > > > On Wed, Jul 20, 2016 at 9:53 AM, Damjan Jovanovic <dam...@apache.org> > wrote: > >> I am back to gbuild, have moved my Windows VM's disk to the faster ext3 >> filesystem, and have begun doing the only thing I can think of to debug >> this: manually "bisection testing" the gbuild-reintegration branch to try >> isolate which patch causes the build performance regression. >> >> There is 136 patches ported from the branches/gbuild branch that have >> been merged in batches to branches/gbuild-reintegration. >> Patch 129 builds in 341 minutes. >> Patch 43 builds in 335 minutes. >> >> So it must be one of the 42 most recent patches. >> Currently compiling patch 16. >> >> >> On Mon, May 23, 2016 at 11:26 PM, Kay Schenk <kay.sch...@gmail.com> >> wrote: >> >>> On 05/05/2016 10:51 AM, Damjan Jovanovic wrote: >>> >>>> Windows XP SP3 32-bit on a VirtualBox instance on FreeBSD, underlying >>>> filesystem is ZFS which does cause I/O slowdown, but not enough to >>>> explain >>>> this. >>>> >>>> Can't remember what compiler I installed; there are Windows SDK 7 and >>>> Visual Studio 9 directories. >>>> >>> >>> Despite the lag, I'd like to get back to this given all your effort so >>> far. >>> >>> Do you still have your config.log? It should show in there what it found >>> for the C compiler. >>> >>> OK, and maybe a crazy idea. Despite the fact that we're having problems >>> with the Win7 build for our usual processing, would it be worth doing a >>> merge INTO the guild branch and setting up an additional win buildbot for >>> that? >>> >>> >>>> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0" >>>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH" >>>> --with-midl-path="$SDK_PATH/bin" >>>> --with-ant-home="/cygdrive/c/apache-ant-1.9.6" --with-dmake-url=" >>>> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2"; >>>> --with-epm-url=" >>>> http://www.msweet.org/files/project2/epm-3.7-source.tar.gz"; >>>> --enable-pch --disable-atl --disable-activex --without-junit >>>> --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio >>>> 9.0/VC" >>>> --with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" >>>> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0" >>>> --disable-directx >>>> --with-package-format="installed" --enable-wiki-publisher >>>> >>>> I am currently thinking we will gain more from porting to Java, than >>>> trying >>>> to maintain a build system for the buggy, leaky, complex, crash-prone, >>>> insecure languages that are C/C++. >>>> >>> >>> I don't know if its C++, which is still very widely used for programming >>> development, or our complicated code, of which I'm guessing, at least 25% >>> could be eliminated. >>> >>> >>> >>> >>>> On Thu, May 5, 2016 at 7:18 PM, Kay Schenk <kay.sch...@gmail.com> >>>> wrote: >>>> >>>> On Tue, May 3, 2016 at 12:07 PM, Damjan Jovanovic <dam...@apache.org> >>>>> wrote: >>>>> >>>>> Unfortunately I discovered a major problem with the >>>>>> gbuild-reintegration branch: on Windows, the build time of trunk is >>>>>> about 3-4 hours, but it's over 12 hours to build gbuild-reintegration >>>>>> :-(. I don't have time to investigate soon, nor do I know where to >>>>>> even begin... >>>>>> >>>>>> >>>>> Hi Damjan, and thanks for this update even it is disappointing. >>>>> >>>>> Could you share what the specifics are for the Windows platform you're >>>>> using for the build? >>>>> >>>>> * specific Windows OS >>>>> * C compiler and flags >>>>> * build options >>>>> * >>>>> >>>>> anything else? >>>>> >>>>> Thanks again for all your work on this. We can work this out. >>>>> >>>>> >>>>> >>>>>> On Tue, May 3, 2016 at 5:20 AM, Pedro Giffuni <p...@apache.org> wrote: >>>>>> >>>>>>> Hello; >>>>>>> >>>>>>> FWIW, I am preparing a second round of spelling fixes ... it's a >>>>>>> quite big change. I would prefer to do such changes *after* the >>>>>>> new build system is in place though. >>>>>>> >>>>>>> I can deal easily with any breakage caused by the spelling fixes but >>>>>>> it may not be very fun to have to fix again the build issues so I >>>>>>> would really prefer to chose the battle field ahead of time ;). >>>>>>> >>>>>>> Pedro. >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> MzK >>>>> >>>>> "Time spent with cats is never wasted." >>>>> -- Sigmund Freud >>>>> >>>>> >>>> >>> -- >>> -------------------------------------------- >>> MzK >>> >>> "Time spent with cats is never wasted." >>> -- Sigmund Freud >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> >> >
