The problem is definitely in r1409590, in the LinkTarget.mk patch. On Fri, Jul 29, 2016 at 2:12 AM, Damjan Jovanovic <dam...@apache.org> wrote:
> 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 >>>> >>>> >>> >> >
