From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24621 invoked by alias); 21 Oct 2013 19:52:23 -0000 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 Received: (qmail 24611 invoked by uid 89); 21 Oct 2013 19:52:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vb0-f47.google.com Received: from mail-vb0-f47.google.com (HELO mail-vb0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 21 Oct 2013 19:52:20 +0000 Received: by mail-vb0-f47.google.com with SMTP id m10so2109144vbh.34 for ; Mon, 21 Oct 2013 12:52:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hwIxy9Q4CEToo7B81cZHVJAdvp+mrP9Y2Xqpi+fY98w=; b=kO/O9Epcu85BlS0UtrS/DkbGXN83bGi9/tpNvj7tHyO74YggxIbsrrJWDQCsQv2vjt 7h499wGAOlvRxh0YdTm//XETobbTtHUpSPytoc0cZOPpYegIW9xHKLo85WiYJHGwa6wv mHmaze4rHls/RnKODFs0mg0krxNd5h55plors2+mNznHMKbKy/qE9Iv6AO/bn6ju3mYQ 8xJBq2NViGknyO8txqftkZk99sTtUOTIR4uI6zemrt3NUI2ssQ3p/Zl+BV/r5jr6xjRX o5QSg5Sa9tdoMBTxEIPUBd9fAIBjHqtKfIWyiDe2ghXpiIQHDcLWNWtcH+1ekuNY0Xoe RhZg== X-Gm-Message-State: ALoCoQlGtT3bgk7N7IlxHbjYlA6ztPtReizRJyrMgpEbADO/dDN/6fGLigpxhB2xiSQ0yoVBVaGpvEje6z2Glyg0pcGQtsuZ2IAxPB9ICBHZb7yW6cLsRsQRVHCpsh1cIren1UDZUjlyhCnfq5M7WOOcpL9aDxu9I3XFPwVIotaNo1l7g/By+HuxFWSIiUChSfhzddgpcAHsQ5lZkYHGWyh5LIHdGYJeOg== MIME-Version: 1.0 X-Received: by 10.52.94.68 with SMTP id da4mr10410453vdb.11.1382385138576; Mon, 21 Oct 2013 12:52:18 -0700 (PDT) Received: by 10.52.37.138 with HTTP; Mon, 21 Oct 2013 12:52:18 -0700 (PDT) In-Reply-To: <877gd6jw68.fsf@fleche.redhat.com> References: <1382032193-9115-1-git-send-email-tromey@redhat.com> <1382032193-9115-10-git-send-email-tromey@redhat.com> <21089.47667.349994.537640@ruffy.mtv.corp.google.com> <87vc0rn2hi.fsf@fleche.redhat.com> <877gd6jw68.fsf@fleche.redhat.com> Date: Mon, 21 Oct 2013 19:52:00 -0000 Message-ID: Subject: Re: [PATCH v2 9/9] add short-circuit logic to elfread.c From: Doug Evans To: Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00668.txt.bz2 On Mon, Oct 21, 2013 at 11:50 AM, Tom Tromey wrote: >>> Nope. I can add it back somehow if you need it. Though at the same >>> time I would like to know what you use it for. I never figured out how >>> the current statistic could be useful. > > Doug> I don't "need" it, it's just good data and was curious. > > The distinction I was trying to draw wasn't whether it was needed or not > needed, but whether it was useful and if so, what for. I read your > response here as saying it is useful. But could you explain what for? > What use is there for it? > > I understand wanting to know the size of the table that is actually > constructed. This is good for seeing where all the memory goes. But I > never thought of a use for "number of minimal symbols we discarded". The comments in the code suggest, to me, the compaction is important. Well, how important? [I realize there are reasons for the compaction other than speed, but according to the comments speed is a real concern here.] The comments say for gdb the table is reduced by 1/3. ref: "over a 1000 duplicates, about a third of the total table size" The comment is a bit out of date (or was miscalculated at the start), I see 0.1%. The comment dates back to at least gdb 4.18. On one of my standard benchmark apps of 1M symbols it is reduced by 0.2%.