This is the mail archive of the gdb-patches@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: [RFA 5/4 take 2] Improved linker-debugger interface


Gary Benson writes:
 > Hi all,
 > 
 > I did some profiling and realised that the probes patch I just mailed
 > had reintroduced calls to update_section_map, a slow function I did
 > some work to avoid calling last year:
 > 
 >   http://www.cygwin.com/ml/gdb-patches/2011-07/msg00460.html
 >   http://www.cygwin.com/ml/gdb-patches/2011-10/msg00361.html
 > 
 > Attached is a patch to avoid calling update_section_map from the
 > probes interface.  Updated timings are as follows:
 > 
 >   no of solibs    100     250     500     1000    2000    5000
 >   ------------------------------------------------------------
 >   old interface     1       3       9       35     141     942
 >   new interface     0       0       1        4      14      89
 >   (times in seconds)
 > 
 > So, with this patch GDB is not three but ten times faster.

Cool.

Not that you have to write it, but if you've got the beginnings of something
already :-), gdb should have a performance testsuite.

It needn't run it with "make check" since it could quite expectedly
increase the time to run the normal testsuite beyond a reasonable threshold.
But we should start collecting testcases to exercise gdb's performance,
and one nice way to do this is to have testcase generators.
I wouldn't want to manually write 5000 shared libs :-), but I do
want to track gdb's performance of handling that much over time,
and it's rather straightforward to write a program that will generate
a specified number of shared libs.
[And similarly for other performance issues we want to track.]

The result of such a testsuite needn't be PASS/FAIL, per se.
As a start it just needs to report numbers.
[Comparing absolute performance depends on the machine used to run the test,
etc. etc. etc.  I think these are solvable problems, and I think this is
something we need to do.]

Thoughts?


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