From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by sourceware.org (Postfix) with ESMTPS id A7AB6385354A for ; Tue, 6 Sep 2022 11:59:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7AB6385354A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=martin.st Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=martin.st Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 286BxeFV023743-286BxeFW023743; Tue, 6 Sep 2022 14:59:41 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 67637A1407; Tue, 6 Sep 2022 14:59:40 +0300 (EEST) Date: Tue, 6 Sep 2022 14:59:39 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: Jan Beulich cc: Nick Clifton , binutils@sourceware.org Subject: Re: [PATCH] ld: pe: Improve performance of object file exclude symbol directives In-Reply-To: <959c6306-60c5-41b7-d22c-18baf3b35ffc@suse.com> Message-ID: References: <20220902105903.2249507-1-martin@martin.st> <174963e9-fa71-b70e-7659-0f534db073f8@redhat.com> <242a402a-57be-0738-d7b8-c19e1a631bb7@suse.com> <2568a388-02a9-4beb-f20b-e2493cda4a64@redhat.com> <959c6306-60c5-41b7-d22c-18baf3b35ffc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-FE-Policy-ID: 3:14:2:SYSTEM X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 6 Sep 2022, Jan Beulich wrote: > On 06.09.2022 13:42, Nick Clifton wrote: >>> On 05.09.2022 14:54, Nick Clifton via Binutils wrote: >>>>> + max_exclude_symbols = ROUND_UP(fdef->num_exclude_symbols + 1, 32); >>>> >>>> Given that the point of this patch is to improve performance when there >>>> are a large number of excluded symbols, incrementing the array by 32 slots >>>> at a time seems counter intuitive. I would suggest a bigger number, eg 1024 >>>> or 10240. >>> >>> Perhaps double the value, thus not overly much impacting the case of there >>> being a moderate number of excludes? >> >> To be honest I have no idea what a "large number of excludes" might look like. >> So maybe 32 is actually a sensible increment. Doubling the increment every >> time the limit is reached could lead to resource exhaustion issues in extreme >> cases, but I doubt if that will ever happen in real life, so that works for me >> too. > > Well, first I was thinking of a hybrid approach - double until reaching 1024, > then increment further by 1024. But then this seemed to be going a little too > far, so I suggested the simpler alternative. Thoughts? FWIW, for the case I'm looking at, the build runs through 52k embedded -exclude-symbols: directives, and out of those, there are 29k unique symbols excluded. // Martin