From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3210 invoked by alias); 17 Dec 2009 20:03:05 -0000 Received: (qmail 2997 invoked by uid 22791); 17 Dec 2009 20:03:04 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Dec 2009 20:02:58 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 3459E1D02E; Thu, 17 Dec 2009 12:02:56 -0800 (PST) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id 293FACD90C; Thu, 17 Dec 2009 12:02:56 -0800 (PST) Message-ID: <4B2A8DE9.5050200@vmware.com> Date: Thu, 17 Dec 2009 20:03:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20090624) MIME-Version: 1.0 To: Marc Khouzam CC: 'Sean Chen' , 'Greg Law' , 'Hui Zhu' , "'gdb@sourceware.org'" Subject: Re: UndoDB's performance References: <5e81cb500912040734u5ce67afdpd6a2d0e63173f908@mail.gmail.com> <5e81cb500912140518r2ad3f2fdrd0dd5a546e6d8a33@mail.gmail.com> <5e81cb500912141840s389859c2r9c56dd8800adb731@mail.gmail.com> <5e81cb500912142326t1bd545ek9180661d8bac10fe@mail.gmail.com> <4B2752C6.4050804@undo-software.com> <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00106.txt.bz2 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).