-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve performance for merging markers from overrides #10018
Conversation
Reviewer's Guide by SourceryThis pull request improves the performance of merging markers from overrides by changing the Sequence diagram for optimized marker mergingsequenceDiagram
participant S as Solver
participant M as MarkerMerger
participant P as Package
S->>M: merge_override_packages(override_packages)
activate M
M->>M: Group packages by identity
M->>M: Check if markers are same across overrides
alt Markers are same
M->>M: Apply performance shortcut
M->>M: Union override markers once
else Markers differ
M->>M: Apply general algorithm
M->>M: Iteratively merge markers
end
M->>P: Update package dependencies
M-->>S: Return merged packages
deactivate M
Class diagram showing the refactored marker merging structureclassDiagram
class Package {
+requires: List[Dependency]
+add_dependency(dep)
}
class TransitivePackageInfo {
+depth: int
+groups: Set
+markers: Dict
}
class BaseMarker {
+intersect(other)
+union(other)
+without_extras()
}
class Solver {
-_provider: Provider
+_solve_in_compatibility_mode(overrides)
+_solve()
}
Package -- TransitivePackageInfo
TransitivePackageInfo -- BaseMarker
Solver -- Package
note for TransitivePackageInfo "Stores package metadata and markers"
note for BaseMarker "Handles marker operations with improved performance"
Flow diagram of improved marker merging processgraph TD
A[Start] --> B[Collect all packages and overrides]
B --> C{Are markers same\nfor all overrides?}
C -->|Yes| D[Use performance shortcut]
C -->|No| E[Use general algorithm]
D --> F[Union override markers]
F --> G[Intersect with package markers]
E --> H[Iteratively merge markers]
H --> I[Union with existing markers]
G --> J[Update package dependencies]
I --> J
J --> K[End]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @radoering - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
dcebda6
to
4ef2df2
Compare
Pull Request Check List
Related to: #9956
This is far from fixing the regression reported in #9956. It "just" improves the performance (compared to Poetry 2.0) significantly.
Using the simplified repro from #9956 (comment) (thanks @dimbleby 🙏), Poetry 1.8 can solve it in 0.2 s, no matter if there is only one extra or 14 extras. Poetry 2 takes longer the more extras are defined:
Summary by Sourcery
Tests: