Very slow CLI and possible cancelled call bugs on Windows
Hi,
This has been raised a few times in the past which I've seen and so let it be as it was always replied to suggesting that it was being actively worked on. But performance of the CLI on Windows is abysmal and actually just getting worse in later releases. Moreover the behaviour is suggestive of true bugs, imho, as I show below.
But it never takes less than 5s in v2.13.1 to return a result, and older versions never take less than 4.9s. This is far from what any CLI tool user would accept and slows our workflows dramatically. We really want to make 1Password central to our organisation but this makes it unusable for widespread adoption.
I upgraded to the latest this morning to 2.13.1 and it's worse than the previous versions I was using (only by a little, but still). I was on v2.3 as v2.6+ claimed perf improvements but they weren't apparent in testing. I've given the timings and suggestions on timing below. It really makes it unusably slow as a secrets manager and since the lack of caching in Windows has been acknowledged for ~a year, it really seems like the team doesn't care about supporting Windows despite this being the majority of the corporate desktop world.
Setup
My standard setup is Windows 11 using Git Bash, but PowerShell is the same. Hardware is very good. Internet connection is WiFi but from a place of little variance (>50Mbps) though I'm unclear if that's even relevant. 1Password desktop client is fine and fast.
I'm based in the UK. If I use a VPN in continental Europe the performance is the same.
We have a few dozen vaults in our account and single-digit thousands of entries. High hundreds of entries in my personal vault.
Summary of conclusions
This is what I conclude from observations:
Windows caching is inactive: this is known and I can't see any updates on progress, but surprisingly it still tries to use it by default despite having a platform specific executable. Only adding --cache=false manually seems to stop this call, but regardless it doesn't affect performance
Previous threads have suggested specifying a vault helps. This doesn't affect performance notably (possibly by 100ms but within the typical noise). I can validate it is using the Vault but I see no difference in timing.
Overall the time seems to be in discrete blocks with a mean of ~2.6s and variance of around 0.3s in 2.13.1. Earlier versions have a slightly reduced mean of ~2.5s but around the same distribution.
The time taken seems to be a discrete multiple of this time with minimum of 2 executions. That is, it never takes less than ~2.6s x 2 (~5.2s +/- the variance) but sometimes takes ~2.6s x 3 or x 4. It's possibly more like "2.8s for the first mandatory call, then ~2.4s x (some integer)" with that first call taking ~1-200ms longer in v2.13 compared to v2.12 and earlier.
The strangest behaviour of all to me is that if I run
op --cache=false --debug --vault Private item get --fields username Dummy
then Ctrl-C it in the first 2.5s before it completes, then run then command again within 5 seconds from the original call, this is the ONLY time I can get it to return in less 3s (actually the only time less than 4.9s) when measuring the time for the second call but it's still 5s overall from the start of the first, cancelled call.
This suggests to me that there is some lengthy ~2.6s initial handshake that the act of Ctrl-C-ing before it returns/runs the second block, then running a second call doesn't repeat this handshake (possibly something to look into for security reasons too if the first calls are doing some sort of handshake that can be reused).
I'll give the raw results below so you can see (apologies for the length but want to give full data upfront).
EDIT: Apparently it's too long to post. I'll try to add it in replies to this post.
1Password Version: 8.9.14
Extension Version: 2.13.1
OS Version: Windows 11
Browser:_ N/A