Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Building with wxWidgets 2.9
ollydbg:
I just test it again right now, the result is:
C::B nightly build against wx2.8.12.
--- Code: ---Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125538 tokens in 0 minute(s), 28.516 seconds).
--- End code ---
C::B trunk build myself against wx2.9.3
--- Code: ---Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125621 tokens in 0 minute(s), 32.652 seconds).
--- End code ---
So, it looks like there are not much difference. :)
ollydbg:
--- Quote from: MortenMacFly on February 18, 2012, 10:21:54 am ---
--- Quote from: ollydbg on February 18, 2012, 08:31:01 am ---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.
--- End quote ---
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... :(
--- End quote ---
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: Strings
--- Quote ---wxChar is defined to be
char when wxUSE_UNICODE==0
wchar_t when wxUSE_UNICODE==1 (the default).
--- End quote ---
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.
Jenna:
--- Quote from: ollydbg on February 18, 2012, 10:24:32 am ---I just test it again right now, the result is:
C::B nightly build against wx2.8.12.
--- Code: ---Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125538 tokens in 0 minute(s), 28.516 seconds).
--- End code ---
C::B trunk build myself against wx2.9.3
--- Code: ---Project 'Code::Blocks' parsing stage done (1419 total parsed files, 125621 tokens in 0 minute(s), 32.652 seconds).
--- End code ---
So, it looks like there are not much difference. :)
--- End quote ---
With wx2.8.12 from debian (64-bit, used compiler unknown):
--- Quote ---Project 'Code::Blocks wx2.8.x - Unix' parsing stage done (1378 total parsed files, 74286 tokens in 0 minute(s), 7.577 seconds).
--- End quote ---
and with self-compiled wx2.9.4 (wx-trunk, 64-bit, compiled with gcc 4.6):
--- Quote ---Project 'Code::Blocks wx2.8.x - Unix' parsing stage done (1851 total parsed files, 75516 tokens in 5 minute(s), 54.683 seconds).
--- End quote ---
The amount of parsed files is significantly different and the time needed for parsing ... :o
stahta01:
Did you turn off all the debugging options in wxWidgets 2.9?
Because I could see them taking a lot of CPU time to run.
Note: Just making a release build is NOT enough to turn the the checking/debugging code off.
See wxDEBUG_LEVEL or DEBUG_FLAG=0.
Tim S.
ptDev:
The setting can be edited in setup.h prior to compiling.
Just uncomment this section:
--- Code: ---// ----------------------------------------------------------------------------
// debugging settings
// ----------------------------------------------------------------------------
// wxDEBUG_LEVEL will be defined as 1 in wx/debug.h so normally there is no
// need to define it here. You may do it for two reasons: either completely
// disable/compile out the asserts in release version (then do it inside #ifdef
// NDEBUG) or, on the contrary, enable more asserts, including the usually
// disabled ones, in the debug build (then do it inside #ifndef NDEBUG)
//
#ifdef NDEBUG
#define wxDEBUG_LEVEL 0
#else
#define wxDEBUG_LEVEL 2
#endif
--- End code ---
Also, it would be interesting to know which wxString implementation 2.9.x uses. I've heard that as of 2.9.x, wxString is a wrapper to std::string (or std::wstring) by default. How does each implementation impact the performance?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version