From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id EC2171F8C6 for ; Wed, 7 Jul 2021 23:22:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230189AbhGGXZb convert rfc822-to-8bit (ORCPT ); Wed, 7 Jul 2021 19:25:31 -0400 Received: from elephants.elehost.com ([216.66.27.132]:31313 "EHLO elephants.elehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230029AbhGGXZa (ORCPT ); Wed, 7 Jul 2021 19:25:30 -0400 X-Virus-Scanned: amavisd-new at elehost.com Received: from gnash (cpe00fc8d49d843-cm00fc8d49d840.cpe.net.cable.rogers.com [173.33.197.34]) (authenticated bits=0) by elephants.elehost.com (8.15.2/8.15.2) with ESMTPSA id 167NMbCq058773 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Jul 2021 19:22:38 -0400 (EDT) (envelope-from rsbecker@nexbridge.com) From: "Randall S. Becker" To: "'Junio C Hamano'" , "=?utf-8?Q?'=C3=86var_Arnfj=C3=B6r=C3=B0_Bjarmason'?=" Cc: , "'Jeff King'" References: In-Reply-To: Subject: RE: [PATCH 2/3] strbuf.h API users: don't hardcode 8192, use STRBUF_HINT_SIZE Date: Wed, 7 Jul 2021 19:22:32 -0400 Message-ID: <057901d77386$f9496e30$ebdc4a90$@nexbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQIlbOLtgAnMEnBo0WJBBQDIMqEADALU4JwAAmE3g1yqcoMwAA== Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On July 7, 2021 6:38 PM, Junio C Hamano wrote: >To: Ævar Arnfjörð Bjarmason >Cc: git@vger.kernel.org; Jeff King >Subject: Re: [PATCH 2/3] strbuf.h API users: don't hardcode 8192, use STRBUF_HINT_SIZE > >Ævar Arnfjörð Bjarmason writes: > >> Change a couple of users of strbuf_init() that pass a hint of 8192 to >> pass STRBUF_HINT_SIZE instead. >> >> Both of these hardcoded occurrences pre-date the use of the strbuf >> API. See 5242bcbb638 (Use strbuf API in cache-tree.c, 2007-09-06) and >> af6eb82262e (Use strbuf API in apply, blame, commit-tree and diff, >> 2007-09-06). >> >> In both cases the exact choice of 8192 is rather arbitrary, e.g. for >> commit buffers I think 1024 or 2048 would probably be a better default >> (this commit message is getting this commit close to the former, but I >> daresay it's already way above the average for git commits). > >Yes, they are arbitrary within the context of these callers. > >I do not think using STRBUF_HINT_SIZE macro in them is the right thing to do at all, as there is no reason to think that the best value for >the write chunk sizes in these codepath has any linkage to the best value for the read chunk sizes used by strbuf_read() at all. When >benchmarking reveals that the best default size for >strbuf_read() is 16k, you'd update STRBUF_HINT_SIZE to 16k, but how do you tell that it also happens to be the best write buffer size for >the cache-tree writeout codepath (answer: you don't)? And benchmark results are going to be highly platform dependent, as we have seen with our exotic platform. -Randall