Attention massive speed up of the debugger

[oBFusCATed]

Hello,
here is a patch that improves the performance of the debugger massively.

The patch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_speedup.patch
It is against the debugger branch, but should apply in trunk (I've tested it and it worked against r5853)

How to test:
1. open some project
2. start debugging
3. stop on a breakpoint
4. open as many dbg windows as possible (call stack, threads, watches)
5. add many watches, complex variables are better (vectors will be great)
6. single step, through the code and see how the debugger toolbar is disable while the debugger is processing things

Execute the test before and after you've applied the patch.

What the patch does:
It adds a flag to the PipeProcess class, that controls if we will get notifications for every line of output or a single notification with the whole output.
The default value is set to notification for every line (the old behaviour).
With the patch only the debugger will use the new behaviour.

It seems that event passing is not so cheap in wx after all.

Have fun, feadback is quite welcome

p.s. I'm using the patch for some days now and I've not seen any problems only benefits

[oBFusCATed]

No one interested?  :shock: :? 

[thomas]

I tried to apply your patch, but it complains that debuggergdb.cpp and pipedprocess.h have some mismatching lines.

[oBFusCATed]

Can you post the output of the patch command?

I've tried to apply it on trunk and on the debugger branch and it works. (as I've written in my post)

[ollydbg]

No one interested?  :shock: :? 

I thought it was already applied in the trunk.

[thomas]

Can you post the output of the patch command?

I've tried to apply it on trunk and on the debugger branch and it works. (as I've written in my post)

Right-clicked with TortoiseSVN, and it said "fetching revision... (some number)" and then it said "the line (blah blah) does not match, maybe the file is out of date?"

[oBFusCATed]

Can you try with command line patch tool, because it spits more output?
I'm using (when I'm on windows) the one from UnixUtils and it seems to work.

[stahta01]

Applying to trunk; as of yesterday SVN ???? Not on partition with full SVN Tools. It was updated yesterday sometime.

Tim S.

Code Select Expand


patch --backup-if-mismatch --unified --strip=0 --ignore-whitespace --forward --input=..\Patches\temp\dbg_speedup-CRLF.patch
patching file src/plugins/compilergcc/compilergcc.cpp
patching file src/plugins/debuggergdb/debuggergdb.cpp
Hunk #1 succeeded at 1035 (offset 394 lines).
patching file src/sdk/pipedprocess.cpp
patching file src/sdk/toolsmanager.cpp
patching file src/include/pipedprocess.h
Hunk #2 succeeded at 35 with fuzz 1.


[thomas]

 
F:\codeblocks src>patch --backup-if-mismatch --unified --strip=0 --ignore-whitespace --forward --input=dbg_speedup.patch
patching file `src/plugins/compilergcc/compilergcc.cpp'
Assertion failed: hunk, file patch.c, line 321

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[eranif]

F:\codeblocks src>patch --backup-if-mismatch --unified --strip=0 --ignore-whitespace --forward --input=dbg_speedup.patch
patching file `src/plugins/compilergcc/compilergcc.cpp'
Assertion failed: hunk, file patch.c, line 321

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

This usually means that the patch was created on Windows with CRLF ('\r\n', vim: ^M), just convert EOLs to LF ('\n')

Eran

[MortenMacFly]

No one interested?  :shock: :? 

Stay tuned... I have it applied since day 0, but was on holiday. If unsure after a (longer) while, simply PM me as a reminder.
@Thomas: Looks good to me so far, it's indeed a speedup.

[oBFusCATed]

I've figured it out
Just wanted to make some noise...

For the record it works perfectly on linux - arch 32bits, gentoo 64 bits ...

p.s. maybe other users (the compiler plugin in particular) of PipeProcess should be modified, so they can take advantage of the speedup

[Jenna]

I've figured it out
Just wanted to make some noise...

For the record it works perfectly on linux - arch 32bits, gentoo 64 bits ...

p.s. maybe other users (the compiler plugin in particular) of PipeProcess should be modified, so they can take advantage of the speedup

Your patch accidently slipped in r5876 (scrollingdialog) and it breaks debugging on my XP-machine, linux still works fine.
Creating the debuggers pipedprocess with eatEOL set to true also works, but with eatEOL set to false, debugger always hangs.
"Tested" with gdb 6.8.50 and 7.0.2.
I will revert the patch and try to find the problem (if possible).

EDIT:
Done (r5898),

sorry for any problems that might have occurred.

[MortenMacFly]

Your patch accidently slipped in r5876 (scrollingdialog) and it breaks debugging on my XP-machine, linux still works fine.

Huh? That works fine for me here (WinXP, too)...?! How do you "reproduce" the hang?

[Jenna]

Your patch accidently slipped in r5876 (scrollingdialog) and it breaks debugging on my XP-machine, linux still works fine.

Huh? That works fine for me here (WinXP, too)...?! How do you "reproduce" the hang?

Create a console-project, compile, set a breakpoint, start the debugger and the bp is never reached.
I also can not stop the debug-process, only kill it via taskmanager.

gdb uses 0% of my CPU and only very moderate ram (just a simple hello-world-program).

gcc 4.4.1 TDM-2 (sjlj),
gdb either shipped with TDM's MinGW (6.8 ) or 7.0.2.

As written before:

Creating the debuggers pipedprocess with eatEOL set to true also works, but with eatEOL set to false, debugger always hangs.