This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Benchmarking (was Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH)
- From: Stan Shebs <stanshebs at earthlink dot net>
- To: gdb-patches at sourceware dot org
- Date: Tue, 14 May 2013 17:13:46 -0700
- Subject: Benchmarking (was Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH)
- References: <20130507140020 dot GA10070 at host2 dot jankratochvil dot net>
On 5/7/13 7:00 AM, Jan Kratochvil wrote:
>
> target-side condition evaluation is a good idea:
>
> time gdb ./loop -ex 'b 4 if i==360000' -ex r -q -ex 'set confirm no' -ex q
> real 1m11.586s
>
> gdbserver :1234 ./loop
> time gdb ./loop -ex 'target remote localhost:1234' -ex 'b 4 if i==360000' -ex c -q -ex 'set confirm no' -ex q
> real 0m21.862s
>
> "set breakpoint condition-evaluation target" really helps a lot.
This reminds me of something that has been on my mind recently -
detecting performance regression with the testsuite.
I added a test for fast tracepoints a while back (tspeed.exp) that also
went to some trouble to get numbers for fast tracepoint performance,
although it just reports them, they are not used to pass/fail.
However, if target-side conditionals get worse due to some random
change, or GDB startup time gets excessive, these are things that we
know real users care about. On the other hand, this is hard to test
automatically, and no wants to hack dejagnu that much. Maybe an excuse
to dabble in a more-modern testing framework? Are there good options?
Stan
stan@codesourcery.com