Repository navigation
perf(1password): warm session once, then resolve apps concurrently - #52
Closed
harrisoncramer wants to merge 2 commits into
Closed
harrisoncramer wants to merge 2 commits into
harrisoncramer wants to merge 2 commits into
Conversation
Owner
Author
|
AI-GENERATED: Closing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 1Password resolver was serializing every op invocation behind a single mutex. That mutex existed for a real reason: against a cold op session, each op call triggers a biometric unlock prompt, so firing them all at once produces a prompt storm. Serializing avoided that but also threw away all the concurrency the runner already sets up, so bringing up the stack paid one sequential op round-trip per app per vault. With ~16 apps resolved against both a base and an override vault that is dozens of serial network round-trips, which is where the multi-second hang on something as small as restarting one service comes from (compose cascades restarts, so every listed app still gets resolved).
The prompt storm only happens while the session is cold. Once any op call succeeds the desktop session is cached account-wide and later calls never prompt. So instead of serializing everything, this gates only the first call: it runs alone, and once it succeeds every later call runs concurrently under the runner's existing limit. A cold first call that fails leaves the gate cold so the next caller is still serialized, which keeps the no-prompt-storm guarantee intact.
On top of that the app-resolution concurrency was a hardcoded 8. Since the warm gate now makes high concurrency safe, this exposes it as a --concurrency flag (settable per invocation or as a default in the ultra config, like the other flags) and raises the default to 16 so a typical project resolves every app in one wave instead of two.
Measured on a 16-app project against a base and override vault, warmed: going from concurrency 1 to 8 drops resolution from ~23s to ~9s, then it flattens (8/16/24 are all within noise of each other). The remaining floor is not the concurrency cap; it is the per-app base-then-override round-trips plus fixed config scan and override generation, which this change does not touch. Batching the op calls into a single invocation is the next lever if we want to push below that floor.