This is the mail archive of the
mailing list for the GDB project.
Re: plugin interface for GDB
>>>>> "Daniel" == Daniel Jacobowitz <firstname.lastname@example.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
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.