Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
cbexaminr:
disclaimer: This is NOT intended to be inflammatory, nor particularly defensive, just informative. Please read it with that mindset.
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---Have you profiled the code?
--- End quote ---
No, not in this context.
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---What improvement in performance do we get by this change?
--- End quote ---
Probably less than 15% yes, but it is combined unnecessary actions like this that add up throughOUT a program to make it slower, and profiling can't really reveal the effect of those, because they're so spread out. Add'l heap fragmentation also tends to slow down everybodies allocations over time. (I've worked on this on a machine that can see c::b/GDB take approx. 20-30 minutes to load c::b for debugging - when I reboot the machine it takes <= 30 seconds. As best I can tell, its probably because of OS virtual memory address space fragmentation, that is eliminated by a reboot.)
While the total disassembly time improvement is likely less than 15%, I'd estimate the local operation percentage gain (of orig. string concat vs .insert) to be possibly 50% gain, but if you like I'll consider* trying to cobble together something to demonstrate this - although it'll be a little harder to prove in a single-threaded context, whereas the effect can be more pronounced in multi-threaded contexts where multiple threads may be thrashing the heap with allocations. (c::b does seem to have multiple threads doing something.) (*Not that I really want to spend my time proving this, for something I know is a wise practice, when the product itself could benefit from further changes.)
I might also note that the original addition of the check for the leading '0x' might have been avoided, with the code and formats being modified for all environments. Of course the trade-off is consistency in all environments (windows vs linux vs ?), vs faster performance vs code maintainability vs risk of changes made to solve original problem. (The current code is probaby 'faster' in linux, because it doesn't have to perform the extra object allocation, both environments have overhead of checking to see if '0x' there to begin with, slower in windows where the object construction and concat are performed, and those lines are less 'maintainable' as there is an 'exception' path ["Is there a leading 0x? No, add one"] that nothing in the code currently indicates the reason for. (Its also dependent on output that is obviously currently different in different environments, and thus probably subject to future change, since it might reasonably be expected to be the same.) (Modification might have been to eliminate use of %p, just use %x and add leading literal '0x' as in '0x%08x', but that could be a problem for 64-bit environs, if that's an issue.) I saw what I thought was an opportunity for 'low-hanging fruit', albeit small in larger context, and took it.
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---If it is less than 15% (I'm sure it is less), please leave it as it is.
--- End quote ---
OK if you like, but see previous note in this response.
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---Also in c++0x this won't be an issue (I think).
--- End quote ---
Why not, what does c++0x provide to help this?
When will c::b be distributed in c++0x (in all environs it serves)?
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---
p.s. There is one general rule: premature optimization is the root of all evil.
--- End quote ---
Scattered failures to avoid unnecessary actions can result in 'fat' that cannot be easily detected or optimized away, short of a rewrite that avoids the unnecessary actions.
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---p.p.s. memory allocations are not problem on the PC for most GUI applications
--- End quote ---
The disassembly process itself is really a 'batch' operation within a GUI. Try stepping into a very 'large' routine, and the pause waiting for disassembly is noticeable, and a bit long for pleasant GUI responsiveness.
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---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.
--- End quote ---
likewise, but I do at times find it indispensable, particularly when trying to debug optimized code that has failed. I tend to prefer mostly working with code as it will be shipped, because I've chased too many problems (multi-threaded, timing-related problems) that simply would not show up in the non-optimized ('debug') code versions. (And no, I've not generally been responsible for creating most of those problems, merely the one stuck with correcting them.) Figuring out what's happening without looking at the disassembly of the optimized code has not been something I could accomplish.
oBFusCATed:
--- Quote from: cbexaminr on September 28, 2010, 11:40:45 am ---
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---Also in c++0x this won't be an issue (I think).
--- End quote ---
Why not, what does c++0x provide to help this?
--- End quote ---
Rvalue references. The temporary should be reused if the classes are written right, but I'm not sure if this is true, have to check it.
--- Quote from: cbexaminr on September 28, 2010, 11:40:45 am ---The disassembly process itself is really a 'batch' operation within a GUI. Try stepping into a very 'large' routine, and the pause waiting for disassembly is noticeable, and a bit long for pleasant GUI responsiveness.
--- End quote ---
Haha, this is another problem an has nothing to do with filling the Disassembly window - http://forums.codeblocks.org/index.php/topic,11298.0.html
--- Quote from: oBFusCATed on September 28, 2010, 10:24:18 am ---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.
--- End quote ---
I've said that I don't use it much, so I can test the improvement in that area. I've not said that the disassebly windows is useless.
cbexaminr:
--- Quote from: oBFusCATed on September 28, 2010, 12:11:38 pm ---Rvalue references. The temporary should be reused if the classes are written right, but I'm not sure if this is true, have to check it.
--- End quote ---
FWIW,
The original expression invokes a global operator+() function which declares a local wxString variable, and then calls a method operator+= to concatenate the items, before returning the result.
No temporary involved in that part of the process.
I think even if it were a temporary, it would be hard for a compiler to optimize away the internal buffer allocation involved in holding the string's actual data, and don't know how or if the class w/could be "written right" to avoid that.
(Unfortunately, as mentioned earlier/elsewhere, it appears that wxWidgets 2.9.x has changed the .insert to also involve the definition of a local class object, although I don't think that object involves a buffer allocation.)
You know, I thought about not trying to make that change, wondering if it would "raise a stink." But I wasn't able to let it pass... :(
cbexaminr:
--- Quote from: oBFusCATed on September 28, 2010, 12:11:38 pm ---Haha, this is another problem an has nothing to do with filling the Disassembly window - http://forums.codeblocks.org/index.php/topic,11298.0.html
--- End quote ---
deleted - posted in the patch thread referenced in quote.
oBFusCATed:
It is not committed because it was not safe
The patch is here http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_speedup_test.patch
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version