|
Boost Users : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-09-16 05:54:26
Martin Slater <mslater_at_[hidden]> writes:
> Well, somebody dropped the ball big time with that. First of all, I found
> Boost.Jam to be extremely complex (nothing like the original Jam, which
> wasn't exactly simple either). But the big problem was performance.
>
> Here's a comparison of a build with the same set of files:
>
> Jam on Windows:
> - Full rebuild: 6m 52s
> - Incremental build: 3.1s
> - Incremental single libray: 0.3s
>
> BoostBuild v2 (3.1.10) on Windows:
> - Full rebuild: 12m 03s
> - Incremental build: 55.5s
> - Incremental single libray: 2.0s
>
> I find the difference in performance simply baffling. How bad can
> you screw up the performance of a full build using the same
> compiler???
This test was subsequently debunked as non-representative: it happened
to hit an odd performance corner in Boost.Build because of the way
artificial source file naming interacted with some of Boost.Jam's
internals. That issue has since been fixed.
http://article.gmane.org/gmane.comp.lib.boost.build/10160
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net