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?
next prev parent 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