From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32048 invoked from network); 16 Nov 2022 19:39:32 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 16 Nov 2022 19:39:32 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1668627572; b=qtNsgJle5QF6zh8tdeFlzR6yhE9pknN6y5XUsslApeEtvUhLAGnWtaHYnInXQxmQ3yh2WQhWnp BsyWOXFE3qQGqmTKJOqNk8DffcRGw6/E6CuIP0KmCbEbwJspxX6FmypxVRXoTIAJqZ4zV37Bs3 TnG5D5ophet27Qs944ozywLkPZUVVGBwJ8iOw5HrcTilzuv8Pmhkoh3Ki31hLKu4PKrNjrv4Hh U2RCn8nPLPB3ZjIYFNMkxuRNnVOtE1u+AbiJMHAEeVnQudzJGHJj6Y3lQyadpuKh4e7IMUzqGI UdwI0ldo5oq6oixedHgbj0dDvpI37yyD6Eclkp4DtbxtLQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (wout3-smtp.messagingengine.com) smtp.remote-ip=64.147.123.19; dkim=pass header.d=jpgrayson.net header.s=fm3 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=jpgrayson.net; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1668627572; bh=S3WZT2oKvVyT5dethQxRjmQ2ixCy9leuppvcXLiFKQU=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:Subject:Cc:To:From: Date:References:In-Reply-To:Message-ID:MIME-Version:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=FOjGt0OCMb/GKQWouMMaQgyjy/TtIYan8OCWAyk5i6Y2BUUvU9Guvismyy9Wfm3nC9BTXc/oSD DaXdUdOtPau0AQaDTufQBZlQCoEYhh8VBTUMK8I9/jZUQ2F3ggUXlPqLGb8BivHhqZD7MzeZ2D kFoybuRoD7vkoiCmz78GzNboYaBGDtuHFKt5J6MWXEl/rofI4gBQghYnlhKt8gsLAIyYXh8vQy QY7JVpF5OUp36biNlVAQMM5rwsy7sMC/HpSyyj3hHqXP6MWlBSFVbnhIVDfzJpDP6/c8pfD3nt FxSudz03nrwkjY338vplbcdWnLBcN5oAHeP0IaQyYLWtxg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Transfer-Encoding: Content-Type:Subject:Cc:To:From:Date:References:In-Reply-To:Message-Id: Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=zh5GfkPHN+3ZWH1cGquOHymlz++3J5uzYE91zNfq8do=; b=r/6s+WPFxuzdWXGfcGbkZt9PSp xdVtmfO5Fz+px1vpnytyJwSRs9TmE7XTv87F4mdQYsjzFtvZCtxvGwv+dRrqTpSCCqnEvU+FCKbgt obXJWoBXltDIMK35M2/+JKUgmgdMIgC2vOjTS3olRp6/dYbhrU2Ic1rOhMrs1FEsqKSDnIL1xky0S 92ii9bUsywGAeCAWVmrzn8IOUCeWek6NrN0BtzVq7Sq0Jnv9pLIBkwsFUANuWr+VRxeOASbJ3UyKO 9lC2uUAs5ljocTSv/dL0o3nP41e+kssiXVVsG/AkYFdufJdk/DhWDchugV3pXDi9SapTHdpCq+voi eZakilHQ==; Received: by zero.zsh.org with local id 1ovOFv-0000ue-Os; Wed, 16 Nov 2022 19:39:31 +0000 Authentication-Results: zsh.org; iprev=pass (wout3-smtp.messagingengine.com) smtp.remote-ip=64.147.123.19; dkim=pass header.d=jpgrayson.net header.s=fm3 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=jpgrayson.net; arc=none Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:48811) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1ovOFa-0000ZI-Th; Wed, 16 Nov 2022 19:39:12 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 82C3332008FD; Wed, 16 Nov 2022 14:39:07 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute4.internal (MEProxy); Wed, 16 Nov 2022 14:39:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpgrayson.net; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1668627547; x= 1668713947; bh=zh5GfkPHN+3ZWH1cGquOHymlz++3J5uzYE91zNfq8do=; b=Q DFVnnDuYV0QXG8XwGUkjO2n5eaTbUfxcEl74IZ1GN2K/yS0SaQAlHwZ8AJEQSi2u 3bg2lOszP+zMcIqE0k2cu+nw+V1Xh8QnXEULkNBSuCTSd+Vjd5mC3CBMnk3tIqbY kmcrYPYWl1jZRIare7lkRdoWNc8iwMnqMYQu46EGxXd8RPJ74I0W561kmwVsLPAm Nk0FEb6fD1W4o295bRhEIOVxiQMXrLCPHVxaQtP4dY2oO1EgoxwTPQe8BVj55DjR hUaGyXejDXlyLrBKEX3vCBYnM1DDPQJ4HQBXViGKGz2YRifn+IO29l1h2Tkeab+R AP2uoDOzMbQE8AakO/VWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668627547; x= 1668713947; bh=zh5GfkPHN+3ZWH1cGquOHymlz++3J5uzYE91zNfq8do=; b=R kN5rBwEUbTTzkJ+k7Irm6+ZNgCzgXiXGtEwMwwX0kixVIqHFMSr3lV+QI98T2jx7 x0f3tonJq4s1Wu9iEywvlIfffVytD+RDwo0qYsPKJB6pNNK7+T81dlaAWzOy+XGt ZAiNqAia1NgVkFVlcBU2vfXZZkO4Xlq2UhHiVt5/z2z0KGlZDEVu52i8mQOflVGS BOftUeSlidEMFC24u0IB9fiERFH/WkRPAE5jPjmXcPkjdkh8kZ50Ma3eZ6R/zZVi 5ND71Y+Oq4EIHTROb6ZN6gyQG1/Cxv3TYeQE4IYALVMSu/war27xyB9u+uimBgSH wR5BdNOlTUeb1Ov/6gYvw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgeeigdduvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvvefutgfgse htqhertderreejnecuhfhrohhmpedfrfgvthgvrhcuifhrrgihshhonhdfuceophgvthgv sehjphhgrhgrhihsohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeekffetlefhhfegud egiefgleejgfetfeevvddvieetteekgfeitdegkeeigeekjeenucffohhmrghinhepuggv sghirghnrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesjhhpghhrrgihshhonhdrnhgvth X-ME-Proxy: Feedback-ID: iefe944c0:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id C603931A0064; Wed, 16 Nov 2022 14:39:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <36f6313d-89e7-43ed-98d2-772cf733d793@app.fastmail.com> In-Reply-To: <20221114131549.GA31023@tarpaulin.shahaf.local2> References: <20221101030429.38029-1-pete@jpgrayson.net> <20221111114928.GF27622@tarpaulin.shahaf.local2> <603fd1b9-1b11-4729-99cb-19e1c4ef8b37@app.fastmail.com> <20221113043040.GG27622@tarpaulin.shahaf.local2> <20221114131549.GA31023@tarpaulin.shahaf.local2> Date: Wed, 16 Nov 2022 14:38:46 -0500 From: "Peter Grayson" To: "Daniel Shahaf" Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Remove StGit patch detection from vcs_info Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Seq: 50983 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Mon, Nov 14, 2022, at 8:15 AM, Daniel Shahaf wrote: > Peter Grayson wrote on Sun, Nov 13, 2022 at 22:38:50 -0500: >> On Sat, Nov 12, 2022, at 11:30 PM, Daniel Shahaf wrote: >> > What's the impact on people who don't have stg(1) installed, or who= have >> > stg(1) installed but are currently in a worktree that doesn't use S= tGit? >> > I.e., are those figures immediately after `git init`, or in a workt= ree >> > that has a StGit patch stack, or? >>=20 >> Without stg(1) installed, the cost would be however long it takes zsh= to >> determine that the executable is not available in $path, which is >> ostensibly very fast (microseconds?). >>=20 >> If stg(1) is installed, but run in a repo with a branch that has not = been >> initialized with `stg init`, it's still about 12ms. Almost all that t= ime >> is taken just to initialize a libgit2 Repository structure, which is >> used to interrogate the object database to determine whether a StGit >> stack is initialized. >>=20 > > I see. > >> > In general, 32ms for everyone might be too much (what if another >> > third-party tool wanted to do its own elif branch that also spent 3= 2ms >> > for everyone? That'd be 64ms in total and counting=E2=80=A6). >>=20 >> Well, that was my original thought as well and why my first patch sim= ply >> removed StGit support from vcs_info. Note that 32ms is on a particula= rly >> fast machine and I stand by my assertion that Python startup time can= be >> on the order of hundreds of milliseconds on more modest machines and/= or >> with older versions of Python. >>=20 > > *nod* > >> > However, if the 32ms would only be seen by users of an EOL'd stg(1), >> > we can relax the threshold a bit. On the other hand, if it's 32ms >> > just in cases where stg(1) is used=E2=80=A6 well, there doesn't see= m to be >> > much we /can/ do there. >>=20 >> The relevant scenarios: >>=20 >> * stg(1) not installed =3D> ~free >> * stg(1) < 2.0 installed =3D> 30+ ms >> * stg(1) >=3D 2.0 installed =3D> ~10 ms >>=20 >> The worst case scenario would be for someone where stg(1) <2.0 is >> installed, but not used. This would create overhead in vcs_info witho= ut >> any value for the user. > > Yeah, the majority of git users don't use stg, so let's try not to make > them wait an extra 30ms for every prompt. > > Fortunately, that delay only happens with EOL versions of stg(1). That > gives us some leeway in our design choices. Thinking out loud: > > How likely is it for a vcs_info git user to have stg(1) 0.x or=C2=A01.x > installed and /not/ use it? > > Unfortunately, the prior probability of having 0.x installed isn't > exactly low, since 0.x is packaged in Debian and derivatives and they > don't seem likely to upgrade soon (see the inactivity on > ). That's aside from how quick distros > may or may not be on upgradomg from=C2=A01.x (so far only Homebrew and= Arch's > AUR have it, according to repology). > > Next, in case 0.x or=C2=A01.x is installed, for it to be unused seems = to mean > the OS installation is either shared (more than one human user) or > has a single user who uses stg(1) only in some of their repositories. > > In the former case, the box is likely relatively performant=E2=80=A6 b= ut so is > the box you took the measurements on. In the latter case, opt-in zsty= le > settings with repo-root-name in the context patterns could be used to > selectively enable/disable stg(1) use=E2=80=A6 but that's hardly ideal. > > All of this only affects people with an EOL version of stg(1) installe= d, > but since it affects people who /don't/ use stg(1), we can't really say > "Patches welcome" to the affected people, can we. > > It seems the better course of action here is to get distros to upgrade > to=C2=A02.x, so the problem situation doesn't arise in the first place. > > Until that happens, how about making VCS_INFO_get_data_git integrate > only with stg =E2=89=A52.x by default, citing the EOL status and perfo= rmance > concerns? That is, guard the code being added by =C2=ABif [[ stg vers= ion is > 2.x or newer ]] || user has opted in=C2=BB. > > For the first disjunct, normally we would prefer =C2=ABstg --version=C2= =BB, but > that likewise takes 30ms here (stg=C2=A00.x in a chroot), so I reckon = we'll > want some other approach. Any ideas? I've thought of two options, but > they're both hacky and I'm sure there are much better ones. (For the > record, they are to check whether =C2=AB=3Dstg=C2=BB is a Python scrip= t and to check > whether it's smaller than 2KB.) Another option would be to have zsh invoke `git rev-parse refs/stacks/$gitbranch` to test whether a StGit stack is initialized on the current branch. This takes less than half a millisecond. We could pair this with testing for the existence of the stg executable to make it even faster. The downside of this approach is that it leaks StGit internals into zsh, but this is a pretty small leak and zsh would still use `stg series` to actually get the patch lists. This seems like a good way forward to me. >> All other scenarios seem to end up with the user getting what they >> paid for. > > Is there any chance of optimizing the 10ms case as well? > > For instance, consider a has-stg(1) executable (or shell function) that > returns=C2=A00 if the Git repository in cwd has an initialized StGit s= tack > and returns=C2=A01 otherwise. Would it be possible for has-stg to run= faster > than=C2=A010ms? If so, vcs_info could use this (unconditionally if ha= s-stg > were maintained and shipped as part of StGit; otherwise, conditional on > =C2=ABuse-simple=C2=BB due to the layering violation). WDYT? I've been thinking about this. For the simplest cases of `stg series`, the stack metadata needed to service the command could be obtained using `git cat-file -p refs/stacks/$gitbranch:stack.json` which takes about 0.5ms versus the libgit2 initialization of 11ms. So an optimized `stg series --noprefix --applied` would be closer to 1ms. This same approach could be applied to several stg subcommands, so it wouldn't necessarily be a one-off optimization. Further down the road, I have hopes of the gitoxide[1] project maturing enough to replace libgit2 in StGit. [1] https://github.com/Byron/gitoxide >> > Perhaps hide some or all of the work behind an opt-in switch. (For >> > instance, the default settings show only the topmost applied patch,= so >> > if it's possible to tell stg(1) not to emit any other patches, that >> > might help the code finish more quickly.) >>=20 >> Limiting the output to only the topmost patch will not have a material >> effect on the runtime because of how the overhead is dominated by >> libgit2 initialization. So an opt-in switch would have be all or >> nothing; either try to run stg(1) or not. >>=20 >> Also worth noting is that changing StGit support in vcs_info opt-in >> would be a bit of a regression and would add more configuration >> surface area. Not sure if/how the zsh project does versioning for >> something like this. I did not include such a switch in my latest >> patch because of these issues. >>=20 > > When we make an incompatible change, we document it in the list of > incompatibilities in our NEWS/README files. We can consider doing more > than that (e.g., printing a message at runtime informing the user of t= he > opt-in) as appropriate. > > In this instance, since released zsh only supports StGit=C2=A00.x, > introducing an opt-in would be a regression only for users who upgrade > to zsh=C2=A05.10 not after upgrading stg to 1.x or=C2=A02.x=C2=A0=E2=80= =94 i.e., typically, > users of LTS distros as opposed to rolling distros. > > That being the case, perhaps adding a paragraph to the list of > incompatibilities in NEWS/README would suffice? Upgrading an LTS dist= ro > does usually involve reading through a long list of incompatible chang= es > that affect some users only. > > Alternatively, perhaps add a runtime message along the lines of: > . > if (( ! OPTED_OUT_OF_THIS_MESSAGE )) && > type stg > /dev/null && > [[ -z ${(M)${(f)$(git for-each-ref)}:#*stgit*} ]] > then > # tell the user they may want to set the opt-in > fi > . > , though I wonder now whether that last conjunct is fast enough=E2=80=A6 I'm going to take a shot at making the StGit stack detection cheap enough that vcs_info can just merrily support StGit without configuration switches, user-facing messages, or incompatibility notices. Thanks again for your detailed consideration of this topic. Pete