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/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
