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: [PATCH 1/3] Test on disassemble


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

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