Skip to main content
May 18, 2024
Question

"op read" is pretty slow, ~700ms per invocation

  • May 18, 2024
  • 11 replies
  • 1145 views

Hi all,

I've noticed that op read is pretty slow, taking on the order of 700ms per invocation. Here's a benchmark using the https://github.com/sharkdp/hyperfine tool:


% hyperfine --warmup 3 "op read op://private/op-test/password"
Benchmark 1: op read op://private/op-test/password
Time (mean ± σ): 717.2 ms ± 46.6 ms [User: 118.7 ms, System: 39.6 ms]
Range (min … max): 640.8 ms … 782.3 ms 10 runs

Reading a non-password field is about the same:


% hyperfine --warmup 3 "op read op://private/op-test/username"
Benchmark 1: op read op://private/op-test/username
Time (mean ± σ): 733.2 ms ± 52.1 ms [User: 124.0 ms, System: 41.4 ms]
Range (min … max): 680.8 ms … 815.0 ms 10 runs

And using --cache does not seem to change anything:


% hyperfine --warmup 3 "op --cache read op://private/op-test/password"
Benchmark 1: op --cache read op://private/op-test/password
Time (mean ± σ): 718.8 ms ± 50.3 ms [User: 119.6 ms, System: 39.6 ms]
Range (min … max): 653.7 ms … 806.7 ms 10 runs

This is on a 16-inch MacBook Pro with an M3 Max on Sonoma 14.4.1. I've installed op via Homebrew.

I'm not sure what the expectation is, but this seems much slower than I expected.


1Password Version: 8.10.30
Extension Version: Not Provided
OS Version: macOS 14.4.1
Browser: Not Provided

11 replies

May 28, 2025

Hi @1P_SimonH 
Any chance to get any reasonable response from 1password team ?
There are multiple threads on this topic and I didn't see any suggestions from your team how to fix this problem.

1P_SimonH
Community Manager
May 29, 2025

Hi @maver1ck,
I shared with this with the right folks and they don't have any immediate suggestions beyond what @AndyW1P shared about using UUIDs. This has sparked a lot of brainstorming for how we can improve this performance, though, so thank you for flagging it!

May 29, 2025

Hi @1P_SimonH ,
I checked different techniques mentioned in this and other threads and generally speaking they're not doing big difference.
Changing from names to IDs has marginal effect as everything sit in cache.

The problem is that debug mode doesn't show proper timestamps (or maybe I don't know how to enable them) so it's difficult to say what operation is bottleneck.
But from output observation I would say problem lays in first two NM requests.

time op read op://vault/OPENAI_API_KEY/password --debug 
5:24PM | DEBUG | Session delegation enabled 
5:24PM | DEBUG | NM request: NmRequestAccounts 
5:24PM | DEBUG | NM response: Success 
5:24PM | DEBUG | NM request: NmRequestAccounts 
5:24PM | DEBUG | NM response: Success 
5:24PM | DEBUG | InitDefaultCache: successfully initialized cache 
5:24PM | DEBUG | EncryptedKeysets: Cache hit on keyset 
5:24PM | DEBUG | AllVaults: cache hit on vault j2.....................sa 
5:24PM | DEBUG | AllVaults: cache hit on vault bg........................ty 
5:24PM | DEBUG | AllVaults: cache hit on vaultk7.................ny 
5:24PM | DEBUG | VaultItems: cache hit on vault items of vault k7.................ny 
5:24PM | DEBUG | VaultItems: cache hit on vault items of vault k7.................ny 
5:24PM | DEBUG | Item: VaultItems cache hit for vault k7.................ny - validating staleness using item version 
5:24PM | DEBUG | Item: cache hit on item xe...................c474 of vault k7.................ny 
op read op://vault/OPENAI_API_KEY/password --debug 0.05s user 0.03s system 6% cpu 1.274 total