UndoDB's performance

Sean Chen sean.chen1234@gmail.com
Fri Dec 18 10:33:00 GMT 2009

On Fri, Dec 18, 2009 at 11:35 AM, Hui Zhu <teawater@gmail.com> wrote:
> Maybe Marc use the record_wait in linux-nat.c version.
> It will increase the speed a little.
> I did some small test to add some record function to i386-linux-nat.c.
>  It will helpful.
> The main speed issue is the prec need let the inferior keep single step.
> So the prec skip patch can more helpful.
> And the record part can be more intellective.  For example:
> Let record_message decode more than one code.  Then we can let
> inferior exec more than one insn for each cycle.
> Thanks,
> Hui
> On Fri, Dec 18, 2009 at 04:00, Michael Snyder <msnyder@vmware.com> wrote:
>> Marc Khouzam wrote:
>>> My results did seem suspiciously good.  Trying things again, I don't
>>> get the same results at all.  I don't remember my exact orginal test,
>>> but I know PRecord had a problem with recursion, maybe that is what
>>> skewed the results?
>> That problem with recursion was actually in gdb core, not in precord.
>> As long as you're just executing (ie. not reverse-stepping) it would
>> never have showed up.
>> (and it's fixed now).

Hi Hui,

I believe the performance of precord will improve a lot with your
strategy. Thanks.

To record a single instruction (except system call), we need to do the
following three steps
1. parse the instruction
2. store the delta status
3. single step the instruction

Have you tested the execution time (proportion) of each step?

If "single step the instruction" takes more than 90% of the overall
execution time, there will be a great space for us to improve the
performance. You know, we are able to decode several instructions each
time, and we are able to decode hundreds of instructions or even more.
We are even able to simulate the behavior of the whole process, in
case we don't need to care about the shared memory. That's, we have
our own simulator inside. Maybe I am too crazy. Anyway, it highly
depends on the proportion of the three steps.

Best Regards,
Sean Chen

More information about the Gdb mailing list