You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Don't eagerly bind pinned Pieces in Solution. (#1407)
Before this change, constructor for Solution would recursively traverse
the entire piece tree from the root down. It did so looking for pieces
that were pinned, so that it could add them to the pieceState map and
(more importantly) apply any constraints that the pinned piece's state
implies on other child pieces.
Unfortunately, this traversal interacts poorly with the optimization to
format some piece subtrees separately. The Solution constructor for the
root piece would traverse the whole tree, then Solution constructors for
any child pieces being formatted separately would also traverse their
piece trees, and so on.
In practice, it was roughly quadratic. Oops. :(
This change removes that traversal completely. Instead, when a piece is
pinned, we apply any constraints at that point in time and then pin the
constrained pieces.
Then, during solving, Solution looks to see if the piece has a pinned
state before looking at its own bound state map. That way, we never have
to bother redundantly storing the states of pinned pieces in the state
map.
On my machine, this makes the large benchmark about 17% faster.
0 commit comments