|
Boost : |
From: Ben Young (ben_at_[hidden])
Date: 2003-10-01 07:33:53
On Wed, 1 Oct 2003, David Abrahams wrote:
> Ben Young <ben.young_at_[hidden]> writes:
>
> > Hi,
> >
> > Here at Transversal we recently came upon the problem of really slow link
> > times, especially for our Boost Python library bindings, using gcc 3.2.1
> > and 3.2.3. Searching the internet suggested that the problem was in the
> > gcc constant merging across translation units which can be disabled using
> > -fno-merge-constants. However, this didn't fix the problem. Investigating
> > further it appeared that 90% of the time was spent merging the strings of
> > debug constants, and this wasn't being disabled by the option.
> >
> > So we hacked gcc to add a new option which disables this merging. It took
> > our link times for our python bindings from 20mins (on a dual 1Ghz Athlon
> > with 1G ram) to just over 4s, a 300x improvement!
> >
> > I inclose the patch below for all those interested. The option is
> > -fno-merge-debug-strs.
> >
> > Cheers
> >
> > Ben
> > ---
> >
> > P.S As far as I can tell it especially effected our python bindings due
> > to the massive number of symbols produced by boost::mpl. The problem in
> > gcc appears to be a merging algorithm which is quadratic in the number of
> > symbols!
>
> This is some great sleuthing, but doesn't it seem like the right patch
> is to fix the algorithm so it's no worse than linear?
>
Possibly, but that would require a greater knowledge of how it works than
we have time to learn (ld internals are slightly complicated :) ). One
mailing list did mention a patch had gone in, but presumably it wont be
out for a little while. Also the storage requirement increase needed (for
us) is negligable, so it is faster to go without the merging at all. You
can already go without it for constants with gcc, so losing it for
debug_str sections does not seem like a big loss.
I thought about submitting this to the gcc mailing list, but it might be
considered a bit too hacky.
Ben
---
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk