Author Topic: Remote Debugging Slowness  (Read 5881 times)

barrem23

  • Community Member
  • Posts: 7
  • Hero Points: 0
Remote Debugging Slowness
« on: January 30, 2014, 04:58:42 PM »
I am currently attempting to use Slickedit to debug a remote process using GDB.  I connect to the system using a COM port and the performance is extremely slow.  Normally a single step takes anywhere between 6-8 seconds.  If I use command line gdb it is not nearly this bad and I was wondering what is slickedit doing?  It feels like slickedit is reloading the world. 

Are there any ways to make this better?  Is there any sort of debug information that slickedit can collect to help point me to what is going so slowly?


chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Remote Debugging Slowness
« Reply #1 on: January 30, 2014, 05:36:59 PM »
What's the baud rate on the COM port?
How long does listing local variables take from command line gdb?
Have you tried other commands at the command line that would correlate with the GUI windows SlickEdit could be trying to refresh?

barrem23

  • Community Member
  • Posts: 7
  • Hero Points: 0
Re: Remote Debugging Slowness
« Reply #2 on: January 30, 2014, 06:13:52 PM »
The baud rate is 115200 and reading variables with the command line is pretty quick at least compared to slickedit.  Additionally I turned on the profiler in slickedit and attached the output.

Graeme

  • Senior Community Member
  • Posts: 2800
  • Hero Points: 347
Re: Remote Debugging Slowness
« Reply #3 on: January 31, 2014, 10:44:29 AM »
Maybe it's the same problem here.
http://www.eclipse.org/forums/index.php/t/333194/

Have you tried debugging/ single stepping with a trivial/ simplest possible remote process?

Dennis

  • Senior Community Member
  • Posts: 3968
  • Hero Points: 517
Re: Remote Debugging Slowness
« Reply #4 on: February 03, 2014, 01:56:17 PM »
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.
« Last Edit: February 03, 2014, 01:58:40 PM by Dennis »