This is the mail archive of the
mailing list for the GDB project.
RE: [PATCH 1/3] Test on disassemble
- From: "Agovic, Sanimir" <sanimir dot agovic at intel dot com>
- To: 'Yao Qi' <yao at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 25 Nov 2013 07:49:07 +0000
- Subject: RE: [PATCH 1/3] Test on disassemble
- Authentication-results: sourceware.org; auth=none
- References: <1384915860-8805-1-git-send-email-yao at codesourcery dot com> <1384915860-8805-2-git-send-email-yao at codesourcery dot com> <0377C58828D86C4588AEEC42FC3B85A7176B83E1 at IRSMSX105 dot ger dot corp dot intel dot com> <52918848 dot 3020201 at codesourcery dot com>
Thanks for the explanatory notes. See my remarks below.
> -----Original Message-----
> From: Yao Qi [mailto:email@example.com]
> Sent: Sunday, November 24, 2013 06:02 AM
> To: Agovic, Sanimir
> Cc: firstname.lastname@example.org
> Subject: Re: [PATCH 1/3] Test on disassemble
> On 11/20/2013 09:24 PM, Agovic, Sanimir wrote:
> > How about an option to measure performance without a running inferior
> > e.g. exec on top of the target stack? This may eliminate some overhead.
> On target exec, GDB will read data from local executable file, which
> should be quite fast and it won't bring any performance issues.
> We need a running inferior, so that GDB will read data from target, with
> some overhead of communication between GDB and target. We'd like to
> measure the performance like that, and alarm if GDB becomes slow.
Maybe we should rename the test to TargetMemoryRead? If the idea is to
catch memory IO regressions the name reflects the intent better.
> > Does opcode/ provide some kind of null-op disassembler we can
> > use instead of a real ISA? A simple gdb source change or compiler
> > upgrade could make comparative runs quite hard.
> I don't know what kind of simple gdb source change may affect the
> result. If gdb source changes affect the result to some extent, such as
> 30%, such changes are what we want to monitor, right?
Indeed. FYI: I had code refactoring's in mind which shuffle code around and thus
change the size of the targeted functions. Similar affects could be triggered by
compiler upgrades/flags changing inlining heuristics.
This patch looks good to me.
> The process of disassemble is I/O intensive, so probably compiler
> upgrade has minor effects on the result. On the other hand, we should
> avoid changing factors other than GDB itself when measuring GDB performance.
> >> >+
> >> >+from perftest import perftest
> >> >+from perftest import measure
> >> >+
> > I see no use of 'measure', is it still needed?
> No, I'll remove it from these three cases.
> >> >+class Disassemble(perftest.TestCaseWithBasicMeasurements):
> >> >+ def __init__(self):
> >> >+ super (Disassemble, self).__init__ ("disassemble")
> >> >+
> >> >+ def warm_up(self):
> >> >+ do_test_command = "disassemble ada_evaluate_subexp"
> >> >+ gdb.execute (do_test_command, False, True)
> >> >+
> >> >+ def _do_test(self, c):
> >> >+ for func in ["evaluate_subexp_standard", "handle_inferior_event",
> >> >"c_parse_internal"]:
> >> >+ for i in range(c+1):
> >> >+ do_test_command = "disassemble %s" % func
> >> >
> > You may move this to the outer loop. Please use _ if you do not use the value "i".
> Thanks for the tip. I'll post the updated one soon.
> Yao (éå)
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052