GDB is a slow debugger. There is no way around that. Python scripted pretty printing makes it even slower (when the python scripts don't just simply hang).
Yes, it seems faster from the command line, but heh, do you update a view of the current set of stack frames, current locals, auto watches, and watches every time you single step on the command line. Maybe if you did, then you wouldn't think the command line was very fast either. Why does SlickEdit do this? Because that's what a graphical debugger is expected to do.
So, if you say to yourself, heh, I'm not being fair to SlickEdit's GDB performance by asking it to do all those things every time I step, and you hide or close some of those debugger tool windows until you need them, you could get much better performance out of the debugger. When I'm debugging with GDB, I close all the debugger tool windows, except for breakpoints, and a Watches window that I keep hidden until I need it. I also turn off the Python pretty printing. because it is faster to deal with "ugly" variables than to deal with all the problems and performance degradation that the pretty printing creates.
Could SlickEdit update those views on a thread? NO, because the GDB/MI (machine interface) in inherently single threaded, and the performance problem is in getting the data from GDB, not what SlickEdit does with it afterwards.
I wish it were different, I wish I could improve the performance of this very important component of our product, but until GDB sees some major architectural changes, we're all stuck pulling this plow only as fast as a plow will go.
