From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11909 invoked by alias); 18 Dec 2009 03:35:32 -0000 Received: (qmail 11900 invoked by uid 22791); 18 Dec 2009 03:35:32 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f189.google.com (HELO mail-pz0-f189.google.com) (209.85.222.189) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Dec 2009 03:35:22 +0000 Received: by pzk27 with SMTP id 27so1903061pzk.12 for ; Thu, 17 Dec 2009 19:35:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.21.42 with SMTP id y42mr2183588wfi.207.1261107321087; Thu, 17 Dec 2009 19:35:21 -0800 (PST) In-Reply-To: <4B2A8DE9.5050200@vmware.com> References: <5e81cb500912040734u5ce67afdpd6a2d0e63173f908@mail.gmail.com> <5e81cb500912141840s389859c2r9c56dd8800adb731@mail.gmail.com> <5e81cb500912142326t1bd545ek9180661d8bac10fe@mail.gmail.com> <4B2752C6.4050804@undo-software.com> <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> <4B2A8DE9.5050200@vmware.com> From: Hui Zhu Date: Fri, 18 Dec 2009 03:35:00 -0000 Message-ID: Subject: Re: UndoDB's performance To: Michael Snyder Cc: Marc Khouzam , Sean Chen , Greg Law , "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-12/txt/msg00107.txt.bz2 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 wrote: > Marc Khouzam wrote: >> >> My results did seem suspiciously good. =A0Trying things again, I don't >> get the same results at all. =A0I 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). > >