| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
entrypoints
This should improve performance slightly and make the code a bit more readable
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Add bundle binstubs to the main man page
Fixes #5560. Hope I understood correctly, I only added a reference because the full man page was already there.
|
| |/ |
|
| |\
| |
| |
| | |
Sam tries to make bundler fast part 4372894632785
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| | |
[Outdated] Support running when gems are not yet installed
Closes #5553
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Source::Git] Only validate specs once (on download)
Instead of validating every time we setup, only do so when we re-serialize the spec
\c @jules2689
|
| | |/
| |
| |
| | |
Instead of validating every time we setup, only do so when we re-serialize the spec
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
[Resolver] Only include minimal set of conflicting deps in conflict message
This implements a feature that @indirect thought up last week.
Previously, when a resolver conflict occurred, bundler would print _all_ the "conflicting" dependencies, even if some of them were not an issue! No longer. Now, we'll compute the minimal set of conflicting dependencies and only print out the requirement trees for those, which should hopefully make conflict messages less confusing and more actionable for users.
I have some tests for the `VersionRanges` module that I'll push up in a few minutes, but a test for the feature itself is already included.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Change `definition#converge_dependencies` comparison to an iterator for performance
What this addresses
---
Follow up for #5539
Previously, a proc was used to extract name and requirements from dependencies. This was
done twice, `2*O(n)`, and compared as `Set` objects.
This was identified as slow:
** Again, note that tracepoint slows the results in the chart down.
Without `TracePoint`, we run at about 13-15ms.
How this fixes it
---
Now that we use a hash for `@locked_deps`, we can
iterate one of the arrays (`@dependencies`) and compare against entries in `@locked_deps` with `O(1)`
access. This results in `O(n)` access.
The result is that `converge_dependencies`, which used to take 15ms, now takes about 2-3ms.
** Again, note that tracepoint slows the results in the chart down.
Considerations
---
Equality between 2 dependencies, as defined [here for =~](https://docs.ruby-lang.org/en/2.4.0/Gem/Dependency.html), shows us that equality means:
> This dependency will match if the name matches the other's name, and other has only an equal version requirement that satisfies this dependency.
To make sure we do not regress, we need to check the name and the requirements. Looking at the source code, we can actually just compare the deps as that doesnt take into account `type`.
Running the added test from #5354, it passed. So these assumptions seem to hold.
cc @segiddins as you wrote #5354 and reviewed #5539
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
performance
Previously, a proc was used to extract name and requirements from dependencies. This was
done twice, 2*O(n), and compared as Sets. Now that we use a hash for `@locked_deps`, we can
iterate one of the arrays (`@dependencies`) and compare against entries in `@locked_deps` with `O(1)`
access. This results in `O(n)` access.
The result is that `converge_dependencies`, which used to take 26ms, now takes about 13-14ms.
|
| |\ \ \
| |_|/
|/| |
| | | |
[RuboCop] Update to 0.48.0
|
| | |/ |
|
| |\ \
| |/
|/|
| |
| |
| | |
Correct the config option name corresponding to --binstubs
This matches my experimental results at least.
|
| |/
|
| |
This matches my experimental results at least.
|
| |\
| |
| |
| |
| |
| | |
Document that --retry works for update.
Also makes the --jobs doc a little closer to the copy from install.
|
| | | |
|
| | |
| |
| | |
Also makes the --jobs doc a little closer to the copy from install.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Change LockFileParse dependencies class variable from an array to a hash
What this addresses
---
The LockFileParser dependenies class variable is used throughout definition
using a series of select and find statements. While measuring Bundler performance, it was
noticed that pieces that interacted with @locked_deps took a fair chunk of time.
This chart shows some timings for `Definition.new` which is called during `require 'bundler/setup'`
** Note: The time scale is a little off because `TracePoint` slows it down, but this does show us a slow point we can optimize.
Diving into that a bit more, we can see the following timings
Again, despite the timings being off due to TracePoint, we can see that `locked_source = @locked_deps.select {|d| d.name == dep.name }.last (run 112812 times) :a1, 0.001, 0.182` was run upwards of 113K times for the Shopify application. Each one of these runs would run in `O(n)` time since we are literally iterating the array.
Looking at `LockFileParser`, we can see that the `dependencies` can easily be changed to a hash.
How this addresses it
---
This change makes the dependencies class variable a hash, which reduces the lookup
from `O(n)` to `O(1)` for each usage. Overall, the operation was `O(n^2)` as we iterated the array for each entry in the array. Now it's `O(n)` :tada:
In the Shopify application, this equated to a 20ms performance gain on each bundler/setup.
Some numbers
---
In particular, the `converge_dependencies` method in `definition.rb` took, on average, 24 ms for an application the size of Shopify. By simply changing the `dependencies` class variable, this was knocked down to 12ms. There was also a savings of a few ms on other method calls, such as `converge_locked_specs`.
Overall, I saw the time to `require 'bundler/setup'` from from 744ms to 724ms for a savings of 20ms.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The LockFileParser dependenies class variable is used throughout definition
using a series of select and find statements. While profile Bundler, it was
noticed that pieces that interacted with @locked_deps took a fair chunk of time.
This change makes the dependencies class variable a hash, which reduces the lookup
from O(n) to O(1) for each usage. In the Shopify application, this equated to a 12ms
performance gain on each bundler/setup.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
use yellow color when version appears to be moving backwards
This is very much intended as a work in progress (no tests!) and proof-of-concept .
Closes #5506.
In cases where the _dependencies_ change, it is not always possible to tell if they are going forwards or backwards -- for instance a change from `> 2.0` to `< 2.8` is neither obviously a forward or a backward change.
Hence the behavior here is to always default to the green color unless there are two specific version numbers and the new one is strictly less than the old one, in which case we use the yellow color.
I’d love any code review and any suggestions for the right place to add some tests for this. I think the tests should end up being quite simple -- we can check for `\e[32m` (green) versus `e[33m` (yellow) in the strings sent to the shell, and that’s easy enough -- but I’m simply not familiar enough with the test suite to know the appropriate place and syntax to do that. Suggestions welcome!
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
remove Rails 2.3 from ISSUES.md guide
Rails 2.3 has been EOL since 2013 and i have not seen any issue currently in Bundler's open issues or recently closed that is dealing with it. So i propose we remove it as it no longer has any value.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Require socket in the file that needs it
Closes #5533
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix `bundle gem` command without having git
So the `gem` command is still breaking on master if `git` is not installed on the machine. This is because we're not checking if git is installed before we init a new git repo.
The test for #5466 is also not actually testing if git is not installed, it's only removing the git config which we already have tests for as well.
@segiddins Do you know a way i can stub `Bundler.git_present?` in the sub-process or have `git` appear to not be present in rspec?
|
