Re: UndoDB's performance

[Hui Zhu <teawater@gmail.com>]

The idea is not bad.  If you can do something is better.  :)

Thanks,
Hui

On Fri, Dec 18, 2009 at 18:33, Sean Chen <sean.chen1234@gmail.com> wrote:
> 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
>