public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: "Feng, Bob C" <bob.c.feng@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Carsey, Jaben" <jaben.carsey@intel.com>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: [Patch] BaseTools: Optimize string concatenation
Date: Mon, 10 Dec 2018 12:35:54 +0000	[thread overview]
Message-ID: <20181210123554.ti56dhmlnswgkjqj@bivouac.eciton.net> (raw)
In-Reply-To: <08650203BA1BD64D8AD9B6D5D74A85D16002A384@SHSMSX101.ccr.corp.intel.com>

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


  reply	other threads:[~2018-12-10 12:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 10:16 [Patch] BaseTools: Optimize string concatenation BobCF
2018-11-08 15:26 ` Carsey, Jaben
2018-11-08 16:40 ` Kinney, Michael D
2018-11-09 14:16   ` Gao, Liming
2018-11-09 17:01     ` Kinney, Michael D
2018-11-08 16:52 ` Leif Lindholm
2018-11-09  3:25   ` Feng, Bob C
2018-11-09 11:48     ` Leif Lindholm
2018-11-11  0:41       ` Feng, Bob C
2018-12-05  2:51         ` Feng, Bob C
2018-12-10 10:47           ` Leif Lindholm
2018-12-10 12:09             ` Feng, Bob C
2018-12-10 12:35               ` Leif Lindholm [this message]
2018-12-11  8:48                 ` Feng, Bob C
2018-12-12 18:37                   ` Leif Lindholm
2018-12-13  1:50                     ` Gao, Liming
2018-12-13 10:08                       ` Leif Lindholm
2018-12-13 14:01                         ` Gao, Liming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181210123554.ti56dhmlnswgkjqj@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox