This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: proposed Opengroup action for c99 command (XCU ERN 76)


On Fri, 16 Sep 2005, Zack Weinberg wrote:

> Especially for C++ which constructs a cpp_token array (sort of) representing
> the entire translation unit, it is desirable to make cpp_token *smaller* --
> and it would be relatively easy to win back that 'whole word not used in the
> case of identifiers', so I do not like a solution which starts using that word
> for identifiers.  Note that identifiers and punctuators are vastly more common
> than numbers or strings, in all C-family languages.

As a general principle I'm doubtful of blocking fixes on the basis that 
some other hypothetical future fix conflicts.  If UCN handling is refined 
first then subsequent changes to cpp_token should take account of that and 
avoid regressing; if cpp_token is reduced in size first then subsequent 
UCN handling changes should avoid losing significant performance 
improvements from such a reduction.

Additional information is only relevant for preprocessing tokens before 
they are converted to tokens, so in principle the front end could use a 
smaller version of the structure if necessary.

> I am with Joe Buck in the opinion that even a 1% performance penalty for
> implementing (A) [or (B)] would be too much -- I suggest this be fixed by
> convincing the C++ committee to allow (C) and not just by phase 1
> transformations, thus allowing the existing implementation to conform.

I don't think solutions starting with convincing the committee to fix a 
working part of the standard are generally that practical!

My experience is that 1% compile-time performance differences are in 
practice not distinguishable from noise; even if times are reliably 
measured with under 1% variation they still have a greater than 1% 
dependence on random factors and the 1% difference may no longer show 
given a trivially different compiler or test data.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


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