Xref: utzoo comp.lang.c:23365 comp.lang.c++:5253 gnu.g++:484
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!ken
From: ken@cs.rochester.edu (Ken Yap)
Newsgroups: comp.lang.c,comp.lang.c++,gnu.g++
Subject: Re: A solution to the multiple inclusion problem
Keywords: #include c c++
Message-ID: <1989Oct27.053731.936@cs.rochester.edu>
Date: 27 Oct 89 05:37:31 GMT
References: <14240@well.UUCP> <1989Oct23.191634.6345@cs.rochester.edu> <1989Oct24.060920.28655@cs.rochester.edu> <14291@well.UUCP>
Reply-To: ken@cs.rochester.edu
Distribution: comp
Organization: University of Rochester Computer Science Department
Lines: 21
Address: Rochester, NY 14627, (716) 275-1448

|->But is this really as inefficient as people think? I tried the
|->following on a Sun-4/60
|->
|->% wc grammar0.cc
|->     932    2944   19700 grammar0.cc
|->% g++ -I../h -E grammar0.cc | wc
|->    3728    8219   63497
|->% time g++ -I../h -E grammar0.cc > /tmp/foo.cc
|->0.4u 0.3s 0:01 44% 0+208k 0+9io 0pf+0w
|->
|->Looks pretty insignificant compared to parsing and CG time.
|
|       What are you comparing to what?  Only one time measurement is given.
|This makes it rather meaningless to draw any conclusions.

Sorry, sloppy of me:

% time g++ -I../h -c grammar0.cc
10.5u 2.5s 0:22 57% 0+1532k 34+37io 202pf+0w

5% of the total time is not something I care to worry about at this time.