Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
MortenMacFly:
--- Quote from: cbexaminr on September 27, 2010, 11:24:12 pm ---Anybody interested in trying this? (so far I've only tried winxp sp2, wxwidgets 2.8.10)
--- End quote ---
@oBFusCATed: Will you look into this?
oBFusCATed:
Yes, I'll tonight (but I don't use disassembly much(at all in fact))... If I don't answer soon please remind me.
Btw this one looks bad
--- Code: ---@@ -117,33 +120,83 @@
wxString fmt;
fmt.Printf(_T("%p\t%s\n"), (void*)addr, line.c_str());
if (!fmt.StartsWith(wxT("0x")))
- fmt = wxT("0x") + fmt;
+ fmt.insert(size_t(0), &wxT("0x")[0], wxString::npos) ; //n == npos, insert all of sz
--- End code ---
Why it is needed? what it does?
cbexaminr:
--- Quote from: oBFusCATed on September 28, 2010, 08:27:58 am ---Yes, I'll tonight (but I don't use disassembly much(at all in fact))... If I don't answer soon please remind me.
Btw this one looks bad
--- Code: ---@@ -117,33 +120,83 @@
wxString fmt;
fmt.Printf(_T("%p\t%s\n"), (void*)addr, line.c_str());
if (!fmt.StartsWith(wxT("0x")))
- fmt = wxT("0x") + fmt;
+ fmt.insert(size_t(0), &wxT("0x")[0], wxString::npos) ; //n == npos, insert all of sz
--- End code ---
Why it is needed? what it does?
--- End quote ---
[edit]
"what it does?" - it inserts the passed string into position zero of the existing string, without requiring a new buffer/object allocation, when the existing buffer is already large enough to hold the .insert()d string. [/edit]
Not required, but was trying to avoid the extra object construction (in original code) of extra wxString (and its buffer allocation) on every added line, when the existing allocated buffer might be enough for the extra two characters. In wxWidgets 3.0 (well, 2.9.x), the internals of .insert have changed, its started doing an ('...substring') local object allocation, so any improvement from this might be negated by environment code changes in next major wxWidgets release**. The ugly casts were trying to get the correctly overloaded .insert from among the compiler ambiguities (there might be a cleaner way to achieve that, I didn't go beyond getting the one I wanted.)
--- Quote from: oBFusCATed on September 28, 2010, 08:27:58 am ---... (but I don't use disassembly much(at all in fact))...
--- End quote ---
What!!!???!! Oh, you surely miss much... :)
**I probably should take a closer look at that change, and see if its avoidable and if I could convince the wxWidgets devs to eliminate it if reasonably possible, but I only have so much time, and its not a lot. (I do use disassembly a lot, in other products, hence the time spent here.)
oBFusCATed:
Have you profiled the code?
What improvement in performance do we get by this change?
If it is less than 15% (I'm sure it is less), please leave it as it is.
Also in c++0x this won't be an issue (I think).
p.s. There is one general rule: premature optimization is the root of all evil.
p.p.s. memory allocations are not problem on the PC for most GUI applications
p.p.p.s. I don't need to look into the assembly to fix most of the problems I encounter and I don't do much hardcore optimization work.
cbexaminr:
--- Quote from: cbexaminr on September 27, 2010, 11:24:12 pm ---Anybody interested in trying this? (so far I've only tried winxp sp2, wxwidgets 2.8.10)
patch against wxpropgrid_debugger branch svn R6634
--- End quote ---
Meant to also note - GDB (7.1, maybe 7.2 also), or GDB/c::b, seem to have issues (at least in the 'mixed' mode) when attempts are made to step into code where GDB cannot find the source. I've seen GDB seemingly fail to actually perform the step (looking at debugger(Debug) log window), I've seen it do the step but c::b can't update display because GDB returns 'internal error' warnings about psymtab vs symtab inconsistency (from a 'bt' request), and I've seen it seem to work. I've particularly seen that occur with a routine _Unwind_SjLj_register (something like that), but I think also when it looked for other library modules (which I don't have source for locally) that contained two separate relative path segments (don't currently recall module name) in the debug info filename.
So if you see something strange, check debug log window for gdb output to be sure problem not related to something its doing, or not doing.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version