This is the mail archive of the
gdb-patches@sourceware.org
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.
-Sanimir
> -----Original Message-----
> From: Yao Qi [mailto:yao@codesourcery.com]
> Sent: Sunday, November 24, 2013 06:02 AM
> To: Agovic, Sanimir
> Cc: gdb-patches@sourceware.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 (éå)
Intel GmbH
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