From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1171 invoked by alias); 23 Nov 2009 16:57:22 -0000 Received: (qmail 1163 invoked by uid 22791); 23 Nov 2009 16:57:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Nov 2009 16:56:18 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nANGuD7O004955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Nov 2009 11:56:13 -0500 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nANGuAMq008595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 11:56:12 -0500 Message-ID: <4B0ABEAA.20206@redhat.com> Date: Mon, 23 Nov 2009 16:57:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: =?ISO-8859-15?Q?Andr=E9_P=F6nitz?= CC: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname References: <4B0707E7.5010308@uglyboxes.com> <200911230826.59752.andre.poenitz@nokia.com> In-Reply-To: <200911230826.59752.andre.poenitz@nokia.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00493.txt.bz2 On 11/22/2009 11:26 PM, André Pönitz wrote: > I am really worried about the performance degradation you expect. > > How bad will that be? If we can define a suitable metric, I would be happy to perform any testing/comparisons necessary. > If the deal is "correct but slow" vs "flaky but faster" I surely prefer the > "flaky but fast" side. I have encountered quite a few issues with C++ in > gdb, so yes, that's not nice. But usually one can work around somehow on > the user side. Raw speed on the other hand is nothing the user can improve. I'm more of a "correct over speed" guy myself, but your concern is noted. Maintainers will have to weigh this matter when more information about the impact is known. Like I said: If anyone can define for me a suitable test(s), I would be happy to do whatever necessary to quantify this. Keith