From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23430 invoked by alias); 2 Dec 2009 19:23:39 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 23419 invoked by uid 22791); 2 Dec 2009 19:23:38 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Daniel Jacobowitz Cc: Cary Coutant , Dodji Seketeli , GDB/Archer list Subject: Re: [RFC] Proposal for a new DWARF name index section References: <4A7FE28D.4050901@redhat.com> <4A8D8868.3010302@redhat.com> <20091202051717.GA24978@caradoc.them.org> <20091202173518.GA13838@caradoc.them.org> Reply-To: Tom Tromey Date: Wed, 02 Dec 2009 19:23:00 -0000 In-Reply-To: <20091202173518.GA13838@caradoc.them.org> (Daniel Jacobowitz's message of "Wed, 2 Dec 2009 12:35:18 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q4/txt/msg00074.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> Well, as long as I'm not the one who has to convert the C++ demangler Daniel> into a specification, I guess it's not totally crazy. I still think Daniel> this makes more sense as an internal cache, though, because it's so Daniel> tied to the implementation of both the compiler and debugger. And Daniel> the canonicalization isn't cheap, and doesn't match GCC's internal Daniel> representation of the names; this would slow down GCC to speed up Daniel> debugging. I do think that slowing down the compiler to speed up the debugger would be the wrong tradeoff. I was hoping we could get this for free in the compiler, or nearly so, but now I unfortunately see that I was confused on that point :-(. We could pick a representation close to what gcc already emits -- but then that overly constrains gcc in the future. Caching is interesting but it comes with other problems. We have to manage the cache somehow. And, the cache would not be useful when an object changes. So, I'd prefer a direct approach, if one can be made to work. The index is still an improvement even if we have to do canonicalization when reading. Some initial numbers: warm cache cold cache without canonicalization: ~0.5 sec 5 sec gdb does canonicalization: ~1.7 sec 6 sec gdb cvs head: ~2.4 sec 10 sec There's a fair amount of noise in the warm cache numbers, I'd say +/- 0.2 sec. This is timing "gdb -batch" on a smallish (80 KLOC) C++ program. I still haven't tried my big tests, I'm still working on setting those up. I also still haven't tried the pubnames/pubtypes index. I guess canonicalization is not terrible -- I definitely notice it when the cache is warm, but with a cold cache it doesn't matter. Tom