From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::434; helo=mail-wr1-x434.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E2B8821199B03 for ; Wed, 12 Dec 2018 10:37:18 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id x10so18693326wrs.8 for ; Wed, 12 Dec 2018 10:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=On8S8L1hBLDZdou8dxX0b86oprEK/11AV49Buh/K+xY=; b=d+geVWn8XZG48rjauI+4WJYs5wB6zTKT6ieTznNSNHAmyR59oGhWvwtqkpRfLQ3cgC g6ug1WwLw8qHkRGouBF7ucV9VprpSBEu3PW/7tR1v4EnLqtuzZg4+Dk6Nn61q1la3UEB F4nDnK0ezs1hrCc5bVzodxHr/cHuwGL9/J3ZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=On8S8L1hBLDZdou8dxX0b86oprEK/11AV49Buh/K+xY=; b=H1QbPzc5Sln/mHsugCVMqN4LvqTRZUNad+BolqKqa6WX3HX3VXtOrG7kkunhHRrqAj AIQEFseb6TN4YfyqBZFebgK62Bmat9v2HPGyorzk2CcHm+CkypaUsw7hpdlhZGEsx8gx tTmYiqi0+Q4to0GjbqU3vwHxFbobz9LDDf7BDwr0SM5rceJ13rval6NHyQKx9Jxwl3n5 eQ5HyvszxQ8ozSNW+S2GBsHIbAJow2pIxeqmOFBqnt6wH2VBV0A3P2iwOI0icBVHF93X +55iWofiAJ+cinGzLDA00YkBdSz3M7wDWmiqXu+tgw4GGfp3mUMhZIffzNmn5RgppCk5 OK9w== X-Gm-Message-State: AA+aEWbf6FgzC0acUVcJZ0E0i+ppHWKNzGDCuP7lLlTrTZCIueJmt3Jp YwPSJsonF/JrAwuHnRPMhniW+FHTo2s= X-Google-Smtp-Source: AFSGD/UiIx2wZqQrK/dlh2VGFUFvuEBU+GhQvynHtk7lJM0htdUDfS3UVr9WtPxQwkNB4f7zoPs4pw== X-Received: by 2002:a5d:56d2:: with SMTP id m18mr19690618wrw.113.1544639836537; Wed, 12 Dec 2018 10:37:16 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id l78sm30435719wma.0.2018.12.12.10.37.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 10:37:15 -0800 (PST) Date: Wed, 12 Dec 2018 18:37:14 +0000 From: Leif Lindholm To: "Feng, Bob C" Cc: "edk2-devel@lists.01.org" , "Carsey, Jaben" , "Gao, Liming" Message-ID: <20181212183714.c4gxwinvwukrqync@bivouac.eciton.net> References: <20181108101625.41364-1-bob.c.feng@intel.com> <20181108165238.vhdbx2mc42kefvag@bivouac.eciton.net> <08650203BA1BD64D8AD9B6D5D74A85D15FFFBED5@SHSMSX101.ccr.corp.intel.com> <20181109114840.txogb6tz5u23o4ng@bivouac.eciton.net> <08650203BA1BD64D8AD9B6D5D74A85D15FFFCFF1@SHSMSX101.ccr.corp.intel.com> <08650203BA1BD64D8AD9B6D5D74A85D1600264F9@SHSMSX101.ccr.corp.intel.com> <20181210104736.dbvh5czprog6pe3x@bivouac.eciton.net> <08650203BA1BD64D8AD9B6D5D74A85D16002A384@SHSMSX101.ccr.corp.intel.com> <20181210123554.ti56dhmlnswgkjqj@bivouac.eciton.net> <08650203BA1BD64D8AD9B6D5D74A85D16002ADCC@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <08650203BA1BD64D8AD9B6D5D74A85D16002ADCC@SHSMSX101.ccr.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [Patch] BaseTools: Optimize string concatenation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 18:37:19 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Dec 11, 2018 at 08:48:19AM +0000, Feng, Bob C wrote: > Hi Leif, > > I understand your concern. > > I collected another performance data set based on open source > MinKabylake platform and updated the BZ > https://bugzilla.tianocore.org/show_bug.cgi?id=1288. The data looks > better than Ovmf. It enabled multiple SKU. > > Before I sent those patch, I did verify them on intel real > platforms. It improves the build performance. But it's not > convenient to share those data. So, I have two comments on this: 1) How can it be inconvenient to share information on build times? I don't even care what the names or codenames for those platforms are. If you are unable to tell us why what you have done matters, the code changes do not belong in the public tree. Clearly having good performance numbers for public platforms is the easiest solution for this problem. 2) Submissions of improvements to build system performance should be verified building real platforms. It should not be a question of "find some other platform to get numbers from once we have improved performance for building our confidential platforms". Regards, Leif > > Thanks, > Bob > > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Monday, December 10, 2018 8:36 PM > To: Feng, Bob C > Cc: edk2-devel@lists.01.org; Carsey, Jaben ; Gao, Liming > Subject: Re: [edk2] [Patch] BaseTools: Optimize string concatenation > > On Mon, Dec 10, 2018 at 12:09:23PM +0000, Feng, Bob C wrote: > > For the "customized deepcopy" and "cache for uni file parser" data, > > you can see the AutoGen is not slower. The whole Build Duration is > > longer because Make Duration is longer while Make Duration time > > depends on the external make, compiler and linker. So it's not the > > patch make the build slow down. > > > > Yes, it's not faster either. I think that because the Ovmf platform > > is relatively simple. From the build tool source code point of view, > > the customized deepcopy will take effect if the platform enabled > > multiple SKU or there are many expressions in metadata file to be > > evaluated. And the "cache for uni file parser" needs there are many > > uni files. The Ovmf platform looks not a good platform to demo the > > effect of this patch. > > But surely we should not introduce patches said to improve performance when the only data we have available shows that they slow things down? > > If the performance data is not representative, then it is worthless. > > Don't get me wrong - if you say "and for this secret platform I can't share with you, it improves build performance by X", then I may be OK with a minor slowdown on the platforms I do have available to test, if X is not minor. > > But if the improvement is only theoretical, and we have no evidence that it helps real platforms, it should not be committed. > > Regards, > > Leif