Just a heads up on the build system. I've run some initial tests on a small subset
of the code (2%) and the build speed improvements are encouraging. Once I have
my ducks in a row with that smaller piece of code I'll start grabbing bigger areas
and post some benchmarks.
On 2/17/06, Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]> wrote:
thanks for analyzing the build process ... your results basically
reflect what I expected ;-).
My gut feeling told me about the same, but I love having hard data to prove it .. :-D
I toyed with a similar GNU make based approach, but Jam is slightly more flexible
which results in shorter build script files. With a large project like OO.o, readability
is pretty important IMHO.. GNU make might actually be slightly faster, but we are
talking maybe <5% which isn't worth it..
I'll send you a test version once the prototype passes the initial tests. My first
goal is to build a working Calc using it.
Take care,
Kai
Despite improving the build performance, another advantage of having a
single process building would be to take inter module dependencies into
account while building, which currently are just ignored.
Anyway, if you need some help, drop me note.
Kay
Kai Backman wrote:
> Hi everyone,
>
> I put up some initial build profile results on the Wiki. The top
> three time sinks are: 33% C/C++ compile, 27% dmake/build.pl,
> 22% dependencies (dpcc). So about 50% of our time is spent
> on build or build related activities. Build time on a fast 4GB
> machine is 17h. More details here:
> http://wiki.services.openoffice.org/wiki/BuildSpeedup
> < http://www.google.com/url?sa=D&q=http%3A%2F%2Fwiki.services.openoffice.org%2Fwiki%2FBuildSpeedup>
>
> Looking at the available data the build times can probably be
> decreased by a factor of 4 without source code changes. With small
> source code changes the improvement could be more significant.
>
> I'm currently doing some Jam based build tests in transex3, and
> I'll tackle other parts next. Jam is a build tool written by Christopher
> Seiwald and released by Perforce. They use it internally to build all
> Perforce platform versions and it is used by other FOSS projects like
> Boost, Freetype and Haiku. There is an old but interesting article on
> transitioning from make to Jam here:
> http://www.perforce.com/jam/doc/scm7.html
> < http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.perforce.com%2Fjam%2Fdoc%2Fscm7.html>
>
>
> Jam works by doing a single start up pass where it reads all the build
> files and stats all sources and targets. Once the dependency graph is
> ready the requested number of processes is spawned in parallel.
> The source code is 12k lines of C (+2k lines in a bison parser).
>
> Another alternative would be to change the build system to use
> non-recursive dmake. The effort is probably at par with rewriting the build
> system from scratch in jam. The build.pl/dmake source is 39k lines of C
> and Perl. My very rough estimate for the available speedup would be 1.5-3x.
>
> In any case, IMHO the best strategy would be to roll out an improved
> build without replacing the existing build.pl/dmake system. Developers
> can then switch once the new build system performs measurably better.
>
> Ideas and suggestions most welcome. :-)
>
> Take care,
>
> Kai
>
> --
> Kai Backman, Software Engineer, [EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Kai Backman, Software Engineer, [EMAIL PROTECTED]
