From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28268 invoked by alias); 3 Feb 2011 20:26:33 -0000 Received: (qmail 28260 invoked by uid 22791); 3 Feb 2011 20:26:33 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD 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, 03 Feb 2011 20:26:27 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id A26E6D00E; Thu, 3 Feb 2011 12:26:25 -0800 (PST) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost2.vmware.com (Postfix) with ESMTP id 9AF7B8EDAE; Thu, 3 Feb 2011 12:26:25 -0800 (PST) Message-ID: <4D4B0F71.1020708@vmware.com> Date: Thu, 03 Feb 2011 20:26:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.24 (X11/20101201) MIME-Version: 1.0 To: Markus Alber CC: "gdb@sourceware.org" Subject: Re: performance of multithreading gets gradually worse under gdb References: <8b62d2819c94a232987155aa99e01983@hyperion-imrt.org> <4D49BE4E.9000009@vmware.com> <76bccf1875854ebc69b6a892fb84a976@hyperion-imrt.org> <4D49D016.7000607@vmware.com> <0e69c90ce85e34a24a5bcef1ce391aae@hyperion-imrt.org> In-Reply-To: <0e69c90ce85e34a24a5bcef1ce391aae@hyperion-imrt.org> Content-Type: text/plain; charset=UTF-8; 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: 2011-02/txt/msg00016.txt.bz2 Markus Alber wrote: > > I compiled gdb-6.5 alright and it performs well as usual, without this > problem. Good info. What version of gdb were you using when you detected the problem? I ran your program stand-alone, then under gdb 7.0, then gdb 7.2CVS. On my not-so-new system I got the following times: stand alone: 15m33s gdb 7.0 16m gdb 7.2CVS 16m10s I could not perceive any change in the cycle time from beginning to end. GDB 7.0 did increase its memory footprint by about 3mb during the run (3 percent). So that could indicate some leakage, around 15k per cycle. But I can't see that as the main reason for the slow-down you're reporting, considering that your system is not memory bound. GDB 7.2CVS increased its memory footprint by only about 500kb during the whole run, so you might consider giving that a try. Instructions for getting the latest development sources are here: http://sourceware.org/gdb/current/ If you'd be willing to contribute your little sample program, we might be able to use it for a thread debugging stress test or something. Michael