yesterday, i successful build CB against wx2.9.3 under windows XP, i also notice CC's parser is much much slower than the wx2.8.12.
Oh dear... I have this feeling that its due to the whole wxString ANSI/Unicode abstraction stuff introduced in wx29... 
I guess we need to instrument some time measuring to find out... 
I have also deep analysis the wxString by reading it's document and code.
As I can see, the wxChar is still defined as wchar_t
wxWidgets: wxWidgets: StringswxChar is defined to be
char when wxUSE_UNICODE==0
wchar_t when wxUSE_UNICODE==1 (the default).
But the function wxString::GetChar(n) is much different between Linux and Windows.
Because under Windows, the wxString natively use wchar_t, so GetChar(n) will quickly do a fetch by base+address bias.
But under Linux, the wxString use utf8 format, so it will do more work, which means it should do the dynamic decoding from the beginning of the buffer, and count n "code point", then return the nth "code point" value. Luckily, wxString using a cache, which means the address returned by previous call of GetChar(n) was cached, if the next time, the user call GetChar(n+m), wxString is smart enough to begin the calculation/decoding from the address return from GetChar(n).
As a conclusion, if you have a source file in local disk and this file is encode in UTF8 format. Under windows, it should first convert to wchar_t array when the file is loaded and convert to wxString, because wxString use wchar_t natively in wxString. But under linux, we don't need the conversion, because wxString use natively UTF8 buffer. On the other side, when doing search in the wxString (like call GetChar()), it need do the conversion dynamically. So, from my analysis, there should not me much difference from wx2.8 to wx2.9 in Linux.
