implicit QChar constructors

[Jesse Yurkovich]

About 2 weeks before this list was created I made a small-ish benchmark to see 
how implicit QChar constructors inside loops affected performance (among 
other things).  Basically, the test consisted of assigning a QChar value into 
a normal C array in 2 ways. However, this should extend into comparisions 
against QChar as well (==, !=  mostly) because those need to be constructed 
too.

QChar *m_text = new QChar[80];
BEG_RDTSC();
  for (unsigned int z = 0; z < N; z++) {  m_text[z] = ' ';  }
END_RDTSC();

QChar space(' ');
BEG_RDTSC();
  for (unsigned int z = 0; z < N; z++) {  m_text[z] = space;  }
END_RDTSC();

The second piece of code was, of course, much much faster than the first 
because of all the constructor calls going on (even for small values of N). 
The second loop just used the same value over and over. Code such as the 
above is nearly everywhere in KDE's sources and the most likely culprites for 
implicit QChar being created are of the form: '\t',  '\n',  ' ',  '\r',  etc. 

My question is, would it be worth while to have QT impliment something like 
QChar::tab, QChar::space, QChar::newline  etc.  Inside loops this would 
drastically cut the unnecessary calls down. Disclaimer: it's true that this 
will not automagically give KDE a boost as this is an _extremely_ small 
optimization, but if done in enough places, those cycles start adding up.  
Also, while it does mean several tight loops and other such constructs will 
be much faster, I'd hate to see readability being sacrificed (is it in this 
case?). But then again, if someone knows of a place, lets say in khtml, that 
iterates many many times and does stuff like this ... it's nice to keep in 
mind thats all.

N	|  Percent speedup from base case (12000000 iterations from 0 to N averaged)
-----------
1	| 8%
2	| 15%
4	| 20%
8	| 41%
16	| 50% -- 2x faster when at least 16 such constructors need to be called

-Jesse