[libstdc++ PATH] tr1::bind support

Jonathan Wakely cow@compsoc.man.ac.uk
Wed Mar 23 12:40:00 GMT 2005


On Wed, Mar 23, 2005 at 12:58:56PM +0100, Steven Bosscher wrote:

> On Tuesday 22 March 2005 11:27, Chris Jefferson wrote:
> > Steven Bosscher wrote:
> > > Could you send me a preprocessed file for this?  I want to know
> > > where all that time is going in a non-PCH compile (I have a few
> > > ideas, but I'd like to check them...).
> >
> > Heres a bzip2ed, preprocessed copy of
> > testsuite/tr1/6_containers/tuple/comparison_operators/comparisons.cc.
> > (for 4.1.0 20050315) Have fun ;)
> >
> 
> Blech.  Almost *all* compile time is sucked up in the C++ front end
> name look stuff (at any -On, here at -O0):
> 
> Execution times (seconds)
>  life analysis         :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
>  preprocessing         :   0.30 ( 4%) usr   0.20 (15%) sys   0.59 ( 7%) wall
>  parser                :   1.61 (22%) usr   0.63 (46%) sys   2.41 (27%) wall
>  name lookup           :   5.40 (73%) usr   0.50 (37%) sys   5.65 (64%) wall
>  tree gimplify         :   0.03 ( 0%) usr   0.01 ( 1%) sys   0.03 ( 0%) wall
>  tree CFG construction :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
>  expand                :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
>  varconst              :   0.00 ( 0%) usr   0.01 ( 1%) sys   0.01 ( 0%) wall
>  local alloc           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
>  global alloc          :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
>  final                 :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
>  rest of compilation   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
>  TOTAL                 :   7.40             1.36             8.78
> 
> On a bootstrapped cc1plus of today, oprofile tells me that comptypes
> takes a rediculous amount of time, as does strlen.  Is this a known
> bottleneck in the C++ front end?

I think the names of template specialisations for 20-parameter tuples
will be very long, and will probably only differ at the end of the
strings, so it may not be such a problem with most other code.

jon

-- 
"A great many people think they are thinking when they are merely
 rearranging their prejudices."
	- William James



More information about the Libstdc++ mailing list