[TR1] tr1 functional compile time looks strange
An empty file including only boost/tr1/functional.hpp seems to compile in 3s ... Does any of the latest patches botched something here ?
On Wed, 27 Apr 2011 08:50:34 +0100, John Maddock <boost.regex@virgin.net> wrote:
An empty file including only boost/tr1/functional.hpp seems to compile in 3s ...
Does any of the latest patches botched something here ?
I haven't changed anything in TR1 for some time. Seems OK here, what compiler/platform are you using?
We have the problem on Mac OS X using gcc 4.5 and on linux too. I pinpointed the stuff to result_of. Using std::tr1::Result_of from functional.hpp take roughly 3s. Including boost/utility/result_of is less than 1s.
Does any of the latest patches botched something here ?
I haven't changed anything in TR1 for some time. Seems OK here, what compiler/platform are you using?
We have the problem on Mac OS X using gcc 4.5 and on linux too.
I pinpointed the stuff to result_of. Using std::tr1::Result_of from functional.hpp take roughly 3s. Including boost/utility/result_of is less than 1s.
They're the same result_of, *unless* you've configured TR1 to use GCC's native result_of in which case the issue is out of our hands.... though of course tr1/functional.hpp #includes a whole lot of stuff that utility/result_of.hpp doesn't. John.
On Wed, 27 Apr 2011 15:42:32 +0100, John Maddock <boost.regex@virgin.net> wrote:
They're the same result_of, *unless* you've configured TR1 to use GCC's native result_of in which case the issue is out of our hands.... though of course tr1/functional.hpp #includes a whole lot of stuff that utility/result_of.hpp doesn't.
May end up as noise sorry. Seems my whole box take ages preprocessing whatever. Ran the same test elsewhere and stuff looks normal. I'll investigate though just in case it is a failure releated to gcc darwin.
On Wed, Apr 27, 2011 at 11:41 AM, falcou <Joel.Falcou@lri.fr> wrote:
On Wed, 27 Apr 2011 15:42:32 +0100, John Maddock <boost.regex@virgin.net> wrote:
They're the same result_of, *unless* you've configured TR1 to use GCC's native result_of in which case the issue is out of our hands.... though of course tr1/functional.hpp #includes a whole lot of stuff that utility/result_of.hpp doesn't.
May end up as noise sorry. Seems my whole box take ages preprocessing whatever. Ran the same test elsewhere and stuff looks normal.
I'll investigate though just in case it is a failure releated to gcc darwin.
I think the extra time is simply due to the extra stuff included in functional.hpp. I get the following with boost trunk: $ echo $OSTYPE darwin10.0 $ g++ -dumpversion 4.5.2 $ cat test.cpp #if defined(INC_TR1) # include <boost/tr1/functional.hpp> #elif defined(INC_UTILTIY) # include <boost/utility/result_of.hpp> #elif defined(INC_EXTRA) # include <boost/utility/result_of.hpp> # include <functional> # include <boost/ref.hpp> # include <boost/mem_fn.hpp> # include <boost/bind.hpp> # include <boost/function.hpp> # include <boost/functional/hash.hpp> #endif $ time g++ -Itrunk -DINC_TR1 -c test.cpp real 0m0.432s user 0m0.388s sys 0m0.041s $ time g++ -Itrunk -DINC_UTILITY -c test.cpp real 0m0.021s user 0m0.008s sys 0m0.009s $ time g++ -Itrunk -DINC_EXTRA -c test.cpp real 0m0.429s user 0m0.384s sys 0m0.036s Daniel Walker
participants (3)
-
Daniel Walker -
falcou -
John Maddock