From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5713 invoked by alias); 10 Jul 2018 02:55:30 -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 5704 invoked by uid 89); 10 Jul 2018 02:55:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Jul 2018 02:55:28 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 4F67A1E059; Mon, 9 Jul 2018 22:55:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1531191327; bh=syiKkESXTV34+8gfXo+1tGrXbkAMnHoI9DCXrHfQ6Sk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tYvv7xbxoQ7BnacdnWPjlVQf/lCnEWSxsEclMGx+Vz6wvkgzUYPlXQEeRFQTFKWpU 0LtCO41UVwZVBzZuc+mxvVourjPxJ6L7saJtXSeE4YKpKFJELCTE0DZeb9pb6ZBeRg rd9aK1NOAPSfpCCjRNuqvsuO7YeNuLSFqpbpAtug= Subject: Re: [RFA 26/42] Remove free_pendings To: Tom Tromey , gdb-patches@sourceware.org References: <20180523045851.11660-1-tom@tromey.com> <20180523045851.11660-27-tom@tromey.com> From: Simon Marchi Message-ID: <2161ee9f-d85a-a962-311a-333b6e7c05ee@simark.ca> Date: Tue, 10 Jul 2018 02:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180523045851.11660-27-tom@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00241.txt.bz2 On 2018-05-23 12:58 AM, Tom Tromey wrote: > buildsym.c currently keeps a free list of "struct pending"s. However, > this didn't seem necessary to me, and so this patch removes the free > list. LGTM. It looks like this was to avoid some allocations/deallocations, for performance? Since it's hard to tell if something is worth it performance-wise without data, I made some quick measurements. I compiled GDB with optimizations, then loaded my debug build of GDB in it like this: $ for i in 1 2 3; do /usr/bin/time -a -o after ./gdb /home/simark/build/binutils-gdb/gdb/gdb -readnow -batch; done This is before: 58.66user 5.38system 1:04.47elapsed 99%CPU (0avgtext+0avgdata 2841916maxresident)k 2520inputs+0outputs (1major+679737minor)pagefaults 0swaps 59.24user 5.52system 1:05.07elapsed 99%CPU (0avgtext+0avgdata 2841572maxresident)k 1616inputs+0outputs (4major+679723minor)pagefaults 0swaps 61.50user 5.38system 1:07.36elapsed 99%CPU (0avgtext+0avgdata 2841764maxresident)k 0inputs+0outputs (0major+679732minor)pagefaults 0swaps This is after: 53.14user 4.91system 0:59.02elapsed 98%CPU (0avgtext+0avgdata 2841824maxresident)k 0inputs+0outputs (0major+679713minor)pagefaults 0swaps 52.70user 4.97system 0:58.49elapsed 98%CPU (0avgtext+0avgdata 2842052maxresident)k 0inputs+0outputs (0major+679747minor)pagefaults 0swaps 54.42user 5.30system 1:01.11elapsed 97%CPU (0avgtext+0avgdata 2841764maxresident)k 0inputs+0outputs (0major+679760minor)pagefaults 0swaps So, unless I mixed up "before" and "after", it looks like this patch actually improves the performance of GDB! Simon