This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libstdc++ PATH] tr1::bind support



On Mar 22, 2005, at 7:46 PM, Giovanni Bajo wrote:


Doug Gregor <dgregor@cs.indiana.edu> wrote:

I speculated that it was an issue with preprocessor metaprogramming,
but I was wrong. Chris verified that preprocessing does not help, but
precompiled headers do help, so the bottleneck seems to be in the C++
parser. It's probably not the template metaprogramming per se that's
causing the problem; I think the issue is just that there's a LOT of
code to be parsed.


Any idea why boost::bind does not suffer from the same slowness?

I dug into this a little bit, because it's bothering me, too. I know Boost.Bind only supports ten parameters, as does Boost.Function and Boost.Tuple (some of them can be extended). First I applied Chris's tuple changes so that we could get the full 20 parameters from bind, tuple, function, etc. Well, that caused my machine to start swapping (I only have 256MB RAM). Scale everything back to 10 parameters and I can compile again. Just including <tr1/functional> requires the compiler to grind for 4.2 seconds on average.


What about Boost? Well, I did the same test, including function, bind, and tuple from Boost to see how long it takes to compile. Result: about 1.4 seconds on average. Run everything through the preprocessor and we see why: the preprocessed file for tr1/functional is about twice the size as the preprocessed file for the Boost versions.

Why? It's hard to tell. The TR1 versions of the components in libstdc++ are somewhat more complicated than those in Boost, because, e.g., libstdc++ has (and uses) result_of, contains a full implementation of TR1 reference_wrapper, etc. However, Boost has lots of portability hacks and I would have thought that libstdc++ would have come out ahead overall.

When running the compiler on the preprocessed source code, the parsing of tr1/functional doesn't speed up at all: it still takes about 4.2 seconds, and the Boost example still takes about 1.4 seconds. The preprocessor is not the bottleneck.

What can we do? For one, we can scale back to 10 parameters across the board. It's the minimum requirement, and although I'd like more parameters it just takes too long to compile. But, we're still 3 times slower than the Boost equivalents. We can try to reduce the header dependencies a bit (for instance, <tr1/functional> ends up including <string>, which includes <algorithm>, etc.) and factor out the core parts of <tr1/functional> that <tr1/tuple> needs, so that it doesn't incur all of that overhead. The long-term solution is probably something like variadic templates, but that's a big undertaking for a potentially esoteric feature that still hasn't been completely defined :)

Tomorrow I'll send in a mega-patch that contains bind, the move to 10 parameters, and includes Chris's tuple changes as well.

Doug


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]