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::441; helo=mail-wr1-x441.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 B84012119EF35 for ; Thu, 13 Dec 2018 02:08:42 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id c14so1378393wrr.0 for ; Thu, 13 Dec 2018 02:08:42 -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=kvzpbooo8w/9SmVbxnHY2pFzw2ORHj43RnCWFRT/KYo=; b=NwMaXlaqPbOkMf+3EyVnsZo+xqE2JmgLLr6rlUrnaAeGx1LrOrnIbz6nchu7xbSOdM YaZkW22yYCGGuYIDPGLoJo2I+jix/UabMn/0/xIseaiGCJSgE6gucf4fpD6Vv76qg2MN 3hjaEeht39DchfR/bhtnR97VXqG1YWaY1xyUA= 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=kvzpbooo8w/9SmVbxnHY2pFzw2ORHj43RnCWFRT/KYo=; b=QqVYLr4HKNXk1vELe7N9+3sj+UZnLJ+iFx3tohzpLAgmQ32rj1jKxqagRNMRNJbPSP sjAGKWjBeNRA2ZFK32y4UmnOZF8hb5rV85N/kkEb7UPgkTO0brQbUdQcbjs7kJ8Ge5R3 R6OioG0B+FXcsk/cBuF3jBrVYONb5DpcOKAOIMQ6wZaSX4H6laUZqVfK9oJQZt1R97Ie 7Sd+whGgupZS/1jdRgxTC9VNIi+EjNRDfn2PEPp50QVkuretHpJT0ULm2dFYYQ1bbRoo 1tsIwCdrO+m+Y/sDA/wz/tRiAAhIxom996awL+tKCBsdLn4lYDm7U8S8d7OxlWl6iS9B 1ZCA== X-Gm-Message-State: AA+aEWZ6i8/KAb3cI7yowlr4nGP2yzMfBlaZRrJGP6JgRg7NY1WP0Q+d BamqPtRnreJl2HWb/lEHojb+lQ== X-Google-Smtp-Source: AFSGD/XtQOxI1aLi3rizp0nKVK7VmIziVe9YxtnKmMsp046KHGlIrZ+DxZnexMWzsbWT0kLfHjo74Q== X-Received: by 2002:a05:6000:14f:: with SMTP id r15mr21904404wrx.53.1544695720585; Thu, 13 Dec 2018 02:08:40 -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 m4sm1528855wml.2.2018.12.13.02.08.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 02:08:39 -0800 (PST) Date: Thu, 13 Dec 2018 10:08:38 +0000 From: Leif Lindholm To: "Gao, Liming" Cc: "Feng, Bob C" , "Carsey, Jaben" , "edk2-devel@lists.01.org" Message-ID: <20181213100838.rsdafatvfruhtf43@bivouac.eciton.net> References: <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> <20181212183714.c4gxwinvwukrqync@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14E38BD5F@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E38BD5F@SHSMSX104.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: Thu, 13 Dec 2018 10:08:43 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Liming, Yes, this is fine. But for future submissions, I would like for this sort of information to be provided at the time of posting. Not the full breakdown, but "reduceces build time of platform XXX on hardware YYY by A%/B seconds". Ideally, more than one platform and more than one hardware should be provided, but at least during this initial improvement phase I'm also happy for the assumption being that unless someone else complains, it's fine on others. Regards, Leif On Thu, Dec 13, 2018 at 01:50:35AM +0000, Gao, Liming wrote: > Leif: > Kabylake platform is the real Intel hardware. The MinKabylake is the minimal feature of the Kabylake BIOS. Here is MinKabylake BIOS code https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform > Bob adds the build performance data of MinKabylake into https://bugzilla.tianocore.org/show_bug.cgi?id=1288. > > The original build performance data: > Build Duration: 00:02:23 > AutoGen Duration: 00:00:42 > Make Duration: 00:01:12 > GenFds Duration: 00:00:27 > > After apply the patch, clean build performance is reduced from 2:23 to 1:57. So, I think his patch improves build performance. > Build Duration: 00:01:57 > AutoGen Duration: 00:00:23 > Make Duration: 00:01:12 > GenFds Duration: 00:00:21 > > Thanks > Liming > >-----Original Message----- > >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leif > >Lindholm > >Sent: Thursday, December 13, 2018 2:37 AM > >To: Feng, Bob C > >Cc: Carsey, Jaben ; edk2-devel@lists.01.org; Gao, > >Liming > >Subject: Re: [edk2] [Patch] BaseTools: Optimize string concatenation > > > >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 > >_______________________________________________ > >edk2-devel mailing list > >edk2-devel@lists.01.org > >https://lists.01.org/mailman/listinfo/edk2-devel