Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: dje@google.com
To: Gary Benson <gbenson@redhat.com>
Cc: gdb-patches@sourceware.org, saugustine@google.com
Subject: Re: [RFA 5/4 take 2] Improved linker-debugger interface
Date: Thu, 19 Jul 2012 19:23:00 -0000	[thread overview]
Message-ID: <20488.24252.142398.372836@ruffy2.mtv.corp.google.com> (raw)
In-Reply-To: <20120719151913.GF25093@redhat.com>

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?


  reply	other threads:[~2012-07-19 19:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19 15:19 Gary Benson
2012-07-19 19:23 ` dje [this message]
2012-07-20  9:33   ` Gary Benson
2012-07-19 21:17 ` André Pönitz
2012-07-20 10:02   ` Gary Benson
2012-07-25 18:19     ` Tom Tromey
2012-07-25 18:22 ` Tom Tromey
2012-07-31 12:21   ` Gary Benson
2012-07-31 14:44     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20488.24252.142398.372836@ruffy2.mtv.corp.google.com \
    --to=dje@google.com \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=saugustine@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox