This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #6145 - halfbyte:reduce_dependency_trees_bailout, r=seg…
…iddins Bail out of reducing depency trees on huge dependency conflict sets ### What was the end-user problem that led to this PR? The problem is described in #6114 - An unusually large set of conflicting dependencies leads to bundler get stuck and lead to very unhealthy amounts of memory and CPU time be consumed. ### What was your diagnosis of the problem? This happens because because a too large array is fed into Array#combination in the "reduce_trees" lambda in `version_conflict_message`. ### What is your fix for the problem, implemented in this PR? By simply bailing out when the conflict set is bigger than a certain size, we'll get a result that is similar to what happened in earlier bundler versions but skip a ton of CPU cycles and memory allocations. I've chosen the limit rather unscientifically by playing around with the result set sizes. 15 seems to be a good compromise but really anything larger than 10 should work (and with work I mean "should not usually not have to be invoked"). ### Why did you choose this fix out of the possible options? Reducing the conflict trees has been a rather new addition to bundler, so defaulting back to the old behavior of not reducing the trees seems like an OK option. It may be possible to also optimize the reduction algorithm, but since this is very much an edge case that only happens when using Bundler slightly out of the normal procedures, I think a simple bail out is sufficient. (cherry picked from commit fc341ed)
- Loading branch information