Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

[Definition] Avoid re-resolving when a gemspec has dev deps #5354

Merged
merged 1 commit into from Jan 24, 2017

Conversation

segiddins
Copy link
Member

Inspired by #5349.

Since dev deps are added with type: :development, they are != to the deps retrieved from the lockfile, which have no type. This compares the deps ignoring type completely

@segiddins segiddins added this to the 1.14.3 milestone Jan 24, 2017
@indirect
Copy link
Member

@bundlerbot r+

@bundlerbot
Copy link
Collaborator

📌 Commit 38ff427 has been approved by indirect

@bundlerbot
Copy link
Collaborator

⌛ Testing commit 38ff427 with merge df20d19...

bundlerbot added a commit that referenced this pull request Jan 24, 2017
…rect

[Definition] Avoid re-resolving when a gemspec has dev deps

Inspired by #5349.

Since dev deps are added with `type: :development`, they are `!=` to the deps retrieved from the lockfile, which have no type. This compares the deps ignoring type completely
@bundlerbot
Copy link
Collaborator

☀️ Test successful - status-travis
Approved by: indirect
Pushing df20d19 to master...

@bundlerbot bundlerbot merged commit 38ff427 into master Jan 24, 2017
@segiddins segiddins deleted the seg-gemspec-dev-deps-no-resolve branch January 24, 2017 03:49
segiddins pushed a commit that referenced this pull request Jan 24, 2017
…rect

[Definition] Avoid re-resolving when a gemspec has dev deps

Inspired by #5349.

Since dev deps are added with `type: :development`, they are `!=` to the deps retrieved from the lockfile, which have no type. This compares the deps ignoring type completely

(cherry picked from commit df20d19)
bundlerbot added a commit that referenced this pull request Mar 30, 2017
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:

![image](https://cloud.githubusercontent.com/assets/3074765/24470432/e87f5324-148c-11e7-81c6-3bb4216c4e83.png)

** 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.

![image](https://cloud.githubusercontent.com/assets/3074765/24470454/f7db5638-148c-11e7-8005-1388c4bacea2.png)

** 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
bundlerbot added a commit that referenced this pull request Mar 31, 2017
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:

![image](https://cloud.githubusercontent.com/assets/3074765/24470432/e87f5324-148c-11e7-81c6-3bb4216c4e83.png)

** 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.

![image](https://cloud.githubusercontent.com/assets/3074765/24470454/f7db5638-148c-11e7-8005-1388c4bacea2.png)

** 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants