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::42b; helo=mail-wr1-x42b.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 08E3D21197056 for ; Mon, 10 Dec 2018 04:35:58 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id z5so10264625wrt.11 for ; Mon, 10 Dec 2018 04:35:58 -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=cilW0nFZMLCYSIkX4YHuwlzwurIbolwbJSXJoCVzGX8=; b=SfMI3dRwj9AvbA6Ii9Q2682AWy0hx1lYj5rCLUksZ1ZbC/1RNFduR33tD1dEzs1For SxxYWfVdLR+O10c8Bu46HCNXZRK+xz7TPeeEuSfMoyxjJ6E78vH45dgSvRZT3W0iQmWG VxI5RbAwsy6PQbj8bKSPpxScgjbzffriqMtcA= 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=cilW0nFZMLCYSIkX4YHuwlzwurIbolwbJSXJoCVzGX8=; b=pWCJ4aIo3gFyz0Y8Wj1vRsvmOiGc6AvrvU9pwNFpJMyBuM7sz8DYZRRahYA9TmUYe4 9ufS+wQdYEyM/hmuRLbSK4NqQfu2pI88Fef1YOWHQIAR+0JE8nr30VGR1Mg5qs65gKPr /gJRsYMCrhyJ58R6+yi8KTD6Sin/TJvy/YAxSHZxEygaefnFv4x8Un8mMbDGAsc4UrOJ IYvoOkWEwKE3Vi5gGZf41gDUVjiiW0SeeUNyo6vkAZgsMlGxzX51AR6OjMzWUVopOCBH TVCtV+Iea6vTUW5jrZjaedIZFAVb/2cpKInmAzDvoaSp4XJknNCEV6FPPlAvFanbTuhN NViQ== X-Gm-Message-State: AA+aEWZhaCrx/bU1Ib6gAwZmw54kHGbGyjDVaBLgYxctMACTY5eOPZGb HlNfL0GwxQMYFSOMhmk8STA8DRcGaUE= X-Google-Smtp-Source: AFSGD/UECq6Fq0jp9emHCoIird3OiHRTJ6WO8a+s5M2DBY8X3bWVotwipZBEORxW4H0Eynh3wEoNjA== X-Received: by 2002:a5d:4e0b:: with SMTP id p11mr10789516wrt.227.1544445356835; Mon, 10 Dec 2018 04:35:56 -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 j33sm22893693wre.91.2018.12.10.04.35.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Dec 2018 04:35:56 -0800 (PST) Date: Mon, 10 Dec 2018 12:35:54 +0000 From: Leif Lindholm To: "Feng, Bob C" Cc: "edk2-devel@lists.01.org" , "Carsey, Jaben" , "Gao, Liming" Message-ID: <20181210123554.ti56dhmlnswgkjqj@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> MIME-Version: 1.0 In-Reply-To: <08650203BA1BD64D8AD9B6D5D74A85D16002A384@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: Mon, 10 Dec 2018 12:35:59 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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