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 15061 invoked from network); 14 Nov 2022 13:16:16 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 14 Nov 2022 13:16:16 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1668431776; b=ATCX4/mr/TrMtHi1XpoEiBoWL2a9Vr9IfzQPsiFwryv5JlQdeckrrypPLOWt0GevOYnToCLiox xMtjCvnMUkbf0dVyBDzcPhiL8uWuUwGlQl5HAfeYZWesKgBr3DfK1ofx3U5ipguTO2wpdbb/KN /msXLmwMltfSKtQSZ55uE2CJ5j9DQoo8jwxxAO/kxXTXo+WOvLrfLSYAaQlGO1aZl2ZgiJlZVa aXvZzbmhzY4nF1Qmv+04RMEA/1jVzKHUDiRu2hNfcv0l9x2iqhR1ziMpPmDqGKzHVj+98FiKr4 oYeWmSCL5BT81W6ZE7XedAWRvTgmacO+dLJ8a/t70D0Djg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (out5-smtp.messagingengine.com) smtp.remote-ip=66.111.4.29; dkim=pass header.d=daniel.shahaf.name header.s=fm3 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1668431776; bh=zY8vPXfXoJdl1Y+UW9TpjWKXI0N82UjFi9pEQbE1b90=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=Yay9g4FJH5Tq2+/5MeVlADSwK5E9jzeXPo1eG0sxAWNsaBxbMadNFktgWDZvGyXulBQRi9xAlh emcbghiV5pYRvjUjuSmvhyAjnB3wLYwTyKZCLkp10WdlHAdgSrU2NIM0KNvZ5R+gczAhqGVGT9 zdSvpqHDi+EjeSJCWtk3w09zClN4bRyj4WUvwUV0bRtMJXKgj9ERXwHV7N3bRymfhQwEiOZzc3 VzP8mQS9t1G2aIp6KiCoN3K1JECl1Fj9upWN6R9QQwlFeFjtdus6XdOtkAucHjTsXvUAa+JwCg yQuAx6XuNe6xkVeEKvcLThWbFPMWS9h6+TQukR0DXRuc4Q==; 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:In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID; bh=ZVH9tY2WgerR7UPojzEOxTRZ8iuNdzZEEJIhvRIilRE=; b=iWHKoRfPmd13ZAaMdFaNsmPsRk PmXI9y0+9hq0B5Hn0fMCIV0BkynBIExsOF9zjisNYQUnVDD+PmXO6UTmDpysmzURo5TFIuoPvGA8g hvJh0jjxdEZPuhv3zRTa/GelJ11B4Rx1GjJl8av8UKLz3v+BFN5Q9pgrb6bsIA6gEVTKY1o9vQbsp ydCX8eswlNTEgacLWfZ+zpHPArQ4YhrjVSrhJ+ul7b40j9ojYib6zbU9p8gmqqe5FpjqddN3SrpfO Tw1AkUJl1/wAZBtN3Q8mvVEua/0mVOphZ9B1Q94clAlCeggjtnesDEcWAuziJTFWTprrXAySOXiBZ yBxRuHXA==; Received: by zero.zsh.org with local id 1ouZJu-000MzA-KF; Mon, 14 Nov 2022 13:16:14 +0000 Authentication-Results: zsh.org; iprev=pass (out5-smtp.messagingengine.com) smtp.remote-ip=66.111.4.29; dkim=pass header.d=daniel.shahaf.name header.s=fm3 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none Received: from out5-smtp.messagingengine.com ([66.111.4.29]:39921) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1ouZJa-000Md4-Qa; Mon, 14 Nov 2022 13:15:56 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9497F5C015E; Mon, 14 Nov 2022 08:15:52 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 14 Nov 2022 08:15:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; 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=1668431752; x=1668518152; bh=ZVH9tY2Wge rR7UPojzEOxTRZ8iuNdzZEEJIhvRIilRE=; b=qSHQ325z4fZ4ckHcntNnibg8cD JpkqnY5cvizHL5xZY8gnDlZi3Fta+hTNX2j72i7MnxC5mZHMg7FWAYk9iMesKPJ5 wdlPRkvfvDlkvjivsr+gSMSQr3PVfmVwlITnvWhWpxEHMzHiRTmKAZ3czfBL9h83 etXsZcxTaq4YGucqU+sgm7iG+62WQ86HorTMYQpX2RTu0vEf9RnU34o0LDplh0LE NJMAir1HugLMWIMg+9l6yZ4Nhw37GwE8qphZvaw2yoOBNmJtaJ2Xa4rBjAXCkbz8 9UeEPb0bc53d3OMSClXb78j3XQHAKdM4xOZXRLb9rQDGGc2L4tcoIHPR8pZg== 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=1668431752; x= 1668518152; bh=ZVH9tY2WgerR7UPojzEOxTRZ8iuNdzZEEJIhvRIilRE=; b=K yTJNjBszyNbW5Jtb33qx74ZkVzMTtex1jEHqC0DJIY6FccLcbeIuKrbSRAxT6x5c Sg+J9d/uQcLt+I9HadMb3tm/TXIXQ1VV65WtAM1x55vZhxxfk28er8GN2qK8Hl62 JQW1aVe4CiXtrFcW8KrepfS/zFdeW3vBpcnNK7YIVlgpedNq2LOWiPeEojxJiqNr fF3aWZ1oODX1nPyCZZBzN3vlM67FSIQIgli73CHpHcnPgQYXcQmKL2y5mA1skNHb C5Oc/lxNyr0WSqM+vQdkpJkvHgEvK71wyJY+oY0TeQPLzZBNaU05spnZtxzMHbND KdnsXw9ShE1PHhVwzbavA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgedvgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtugfgjggfsehtkedttddtreejnecuhfhrohhmpeffrghn ihgvlhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpeeiledvtdejhfeltddtteekieefgeeggeevjeehjeethfei ledttdeljeetffeffeenucffohhmrghinhepuggvsghirghnrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggrnhhivghl rdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Feedback-ID: i425e4195:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 14 Nov 2022 08:15:51 -0500 (EST) Received: by tarpaulin.shahaf.local2 (Postfix, from userid 1000) id 4N9qYx1hPzz2Kc; Mon, 14 Nov 2022 13:15:49 +0000 (UTC) Date: Mon, 14 Nov 2022 13:15:49 +0000 From: Daniel Shahaf To: Peter Grayson Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Remove StGit patch detection from vcs_info Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Seq: 50964 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: 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 StGit? > > I.e., are those figures immediately after `git init`, or in a worktree > > that has a StGit patch stack, or? > > 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?). > > 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 time > 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. > 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 32ms > > for everyone? That'd be 64ms in total and counting…). > > Well, that was my original thought as well and why my first patch simply > removed StGit support from vcs_info. Note that 32ms is on a particularly > 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. > *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… well, there doesn't seem to be > > much we /can/ do there. > > The relevant scenarios: > > * stg(1) not installed => ~free > * stg(1) < 2.0 installed => 30+ ms > * stg(1) >= 2.0 installed => ~10 ms > > 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 without > 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 1.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 1.x (so far only Homebrew and Arch's AUR have it, according to repology). Next, in case 0.x or 1.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… but so is the box you took the measurements on. In the latter case, opt-in zstyle settings with repo-root-name in the context patterns could be used to selectively enable/disable stg(1) use… but that's hardly ideal. All of this only affects people with an EOL version of stg(1) installed, 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 2.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 ≥2.x by default, citing the EOL status and performance concerns? That is, guard the code being added by «if [[ stg version is 2.x or newer ]] || user has opted in». For the first disjunct, normally we would prefer «stg --version», but that likewise takes 30ms here (stg 0.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 «=stg» is a Python script and to check whether it's smaller than 2KB.) > 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 0 if the Git repository in cwd has an initialized StGit stack and returns 1 otherwise. Would it be possible for has-stg to run faster than 10ms? If so, vcs_info could use this (unconditionally if has-stg were maintained and shipped as part of StGit; otherwise, conditional on «use-simple» due to the layering violation). WDYT? > > 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.) > > 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. > > 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. > 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 the opt-in) as appropriate. In this instance, since released zsh only supports StGit 0.x, introducing an opt-in would be a regression only for users who upgrade to zsh 5.10 not after upgrading stg to 1.x or 2.x — 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 distro does usually involve reading through a long list of incompatible changes 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… > > From the "Is your computer plugged in?" department: Is that 32ms figure > > on hot disk cache with .pyc files already having been generated? > > Yes. I used hyperfine(1) to do these measurements. *nod* Cheers, Daniel