From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110034 invoked by alias); 19 Feb 2017 21:26:15 -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 110015 invoked by uid 89); 19 Feb 2017 21:26:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:1486930, Hx-languages-length:1408, perfect X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 Feb 2017 21:26:13 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 140EC81229; Sun, 19 Feb 2017 21:26:14 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-221.ams2.redhat.com [10.36.116.221]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1JLQANd009607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Feb 2017 16:26:13 -0500 Date: Sun, 19 Feb 2017 21:26:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Victor Leschuk Subject: Re: [PATCH 3/8] Code cleanup: Split dwarf2_ranges_read to a callback Message-ID: <20170219212609.GB1291@host1.jankratochvil.net> References: <148693097396.9024.2288256732840761882.stgit@host1.jankratochvil.net> <148693098804.9024.9905586065345063380.stgit@host1.jankratochvil.net> <7ffd29af-218a-32e3-ac6a-207f0bc8a382@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ffd29af-218a-32e3-ac6a-207f0bc8a382@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00520.txt.bz2 On Fri, 17 Feb 2017 02:19:06 +0100, Pedro Alves wrote: > std::function is a lot of unnecessary overhead here. Unless you > manage to trigger to small-function optimization (which you won't here, > the callbacks are too big), this is forcing a heap allocation inside > std::function for every call to dwarf2_ranges_process. These microoptimizations lead to the still broken fundamental data types and algorithms of GDB, having to wait for minutes to hours to print an expression (although usually it is not printable anyway). perf would show the problem if it is really significant. It would be less significant with tcmalloc which GNU libc systems still do not use by default. > Let's only use std::function for it's intended use-case of when the > design calls for taking, or more usually, storing, a callable whose > type is not knowable at compile type. You are defining a new C++ specification here? I have checked the code as I wrote it is a perfect use of std::function<> according to the ISO C++11 specification. Thanks you have noticed current GCC has missed-optimization in this case and that it can be workarounded by a template as you have suggested. It leads to worse compilation diagnostics and we can hope this hack can be removed in the future. Still I agree this workaround of GCC is worth the performance gain. Jan