| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
viable candidate (below the deferral tier), clear the "finished" flag.
This avoids a problem where if a deferral was retracted after the
resolver had run out of solutions, we wouldn't find any more answers.
|
|
call recompute_step_tier() on that step.
Necessary since the step might still be waiting to be examined.
|
|
The goal is to find the one and only choice that has the dependency,
so when trying to find a choice in the hash map, we need to use a
choice that has that dependency built in (due to the identity semantics
of choices).
|
|
|
|
|
|
There is a cost in memory to this change. But the win in terms of
speed is *huge*. How huge? Well, when compiled without optimization,
the new code is now 4-5 times faster than the previous code *with*
optimization and something like 20-30 times faster than 0.5.2.
|
|
creating a dep-solvers object.
|
|
shouldn't pass a temporary there, ever.
Turned up with valgrind.
|
|
No noticable performance gains from this -- but I'm not surprised; the
bulk of the non-flat data is probably stored in the choice_set attached
to each solver. Flattening that is the next step.
|
|
This is another step towards switching to a more efficient representation.
|
|
profiling turned on by accident.
Profiling has a nasty tendency to cause very fast functions which are
executed often to appear MUCH more costly than they are.
Reference-counting such as this takes a particular hit.
|
|
In addition to eliminating that code, this change should make it easier
to change the representation of dep_solvers (since I won't have to
figure out how to memory-manage whatever-it-is).
|
|
a solver.
If a solver's tier is below the step's tier, the sanity-check was
claiming that the global promotion which had raised the step's tier
should also apply to the solver, even if it didn't contain that solver.
Fixed by restricting that test to (correctly) only consider promotions
containing the solver in question.
|
|
Previously, we were unable to find promotions that matched a solver and
nothing else.
With these changes, the output of the resolver is identical to the
pre-rewrite version, although it seems to still visit too many nodes.
|
|
child are picked up by the others.
|
|
Output domains are logged now.
|
|
Some dependencies legitimately list a solver twice; we already should
handle this gracefully, and it isn't actually a sign of brokenness
elsewhere.
|
|
soft deps.
It was counting wrong, so these sometimes showed up as containing
promotions they shouldn't have, or as not containing promotions they
should have.
|
|
Needed for the new sanity-checks.
|
|
|
|
These are expensive and compiled out by default, but useful for
empirically verifying that the resolver isn't going wrong. Right
now it is.
|
|
|
|
Previously some of these were being thrown away, because the code was
keeping promotions that were strictly less than the maximum tier (oops).
|
|
and enable the new logging by default with --log-resolver.
Currently, the only INFO level message is the existing promotion that
a new promotion was redundant with.
|
|
|
|
Choices that install a different version of the source of a dependency
should cause solvers of that dependency to be deferred.
|
|
Hopefully this is a bit more scalable.
|
|
different types of choices correctly.
It was returning 3-way comparison results in some cases and Booleans in
others, so totally dissimilar choices ended up comparing "equal".
|
|
the queue.
This was causing steps to be processed multiple times.
|
|
|
|
Makes it easier to write a much simpler renderer.
|
|
|
|
Without this, bad stuff was happening, like spurious entries in the
structural-reasons list that triggered internal sanity checks.
|
|
This doesn't have a practical effect (those steps weren't being
processed anyway), but it does suppress spurious errors in the logs.
|
|
update it, not before.
|
|
|
|
parent step's tier, use the parent step's tier.
Previously, the code was decreasing the tier in the successor.
|
|
Some promotions are never being applied, for reasons that are not
currently clear. The sanity check ensures that promotions are always
applied, and also logs an error if it ever trips, to help track this
down.
|
|
If I need this again, I should probably just make it a separate logging
category -- hopefully I won't, though.
|
|
newly selected version, not just reverse dependencies.
|
|
|
|
The idea is that if there are only "a few" new promotions, it's quicker
to test them individually than to use the full promotion set. The exact
parameters of what "a few" means should probably be configurable at
runtime, not least so I can easily get some statistics on what the
effects of various settings are.
|
|
choice, and to find choices that contain a particular choice.
|
|
|
|
|
|
whenever a promotion is added, just retest tiers when steps are pulled off the queue.
This seems to be a win overall, probably because most of the computation
in the case where lots of promotions have been added is a waste (since
the steps won't be processed anyway, or another promotion will come
along and override the one that was applied). I would still like to
explore a hybrid model, where promotions are applied incrementally if
only "a few" have been added since a step was generated -- that should
vastly speed up scanning smallish subtrees.
|
|
These don't have any impact on performance that I can see one way or
the other -- which probably means they don't hurt much in smaller
cases, so it's a cheap way to avoid scalability surprises since the
hash tables should be better for large inputs.
|
|
promotion set.
|
|
promotion-finding routine.
|
|
non-bool inputs.
|
