-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Use a shared connection pool for fetching gems #7079
Conversation
Closes #7076 Bundler will now use the same (shared) remote fetcher instance that RubyGems uses. This will allow installs to use a shared connection pool, which represents a significant performance improvement on a clean install.
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.
LOL. I had to double take... "how could this be that simple?" I didn't even notice this method on RemoteFetcher but that looks like exactly the right solution.
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.
Hard to beat such a simple patch!
Thank you for the fix @segiddins! When I was thinking about how to solve this, I thought sharing the same fetcher object between multiple threads (when |
That PR addresses my concerns, thanks! |
…ce-in-bundler Reuse Gem::RemoteFetcher instance in bundler (cherry picked from commit 54a7a7a)
…ce-in-bundler Reuse Gem::RemoteFetcher instance in bundler (cherry picked from commit 54a7a7a)
Closes #7076
Bundler will now use the same (shared) remote fetcher instance that
RubyGems uses.
This will allow installs to use a shared connection pool, which
represents a significant performance improvement on a clean install.