This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: plugin interface for GDB


>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Fri, Apr 20, 2007 at 06:21:11PM -0300, Thiago Jung
 Daniel> Bauermann wrote:
 >> I agree that a plugin interface and a scripting language overlap a
 >> lot in terms of functionality. I'm not sure it would cut it in my
 >> specific case... I'm looking at something which will potentially
 >> need to examine 10's of GB of inferior memory in some cases and
 >> I'm a bit worried about the performance. If there was already
 >> scripting language support in GDB, I could do some
 >> benchmarks. It's quite possible that the overhead of the scripting
 >> language would be low or acceptable. But right now I don't want to
 >> work (probably a lot) on developing such support only to find out
 >> it won't meet my performance needs... :-)

 Daniel> Well, it's going to get developed eventually in either case.
 Daniel> If you can't write things fast enough in Python, Python
 Daniel> itself lets you load C modules to do the real work; the
 Daniel> question is how fast GDB can provide memory access to the
 Daniel> Python layer.  And I think the answer is roughly as fast as
 Daniel> GDB could get at it directly.

Very likely.  "Scripting language" often makes people expect low
performance, and for some that may be true (shell scripts?  Tcl
perhaps).

Python is very fast.  It compiles to bytecode, and the execution
machinery seems to work quite well.  I have an application that runs
through very large files, doing some simple string matching.  It runs
at 50 MB/s or better, on a PC.

So I don't think speed will be a concern.

   paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]