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
link kx x l@(Bin sizeL ky y ly ry) r@(Bin sizeR kz z lz rz)
| delta*sizeL < sizeR = balanceL kz z (link kx x l lz) rz
| delta*sizeR < sizeL = balanceR ky y ly (link kx x ry r)
|otherwise= bin kx x l r
This is just like #1053, that the common case is one where no balancing is required, and making sure that's fast pays off.
I'll prepare a PR for it.
While I'm here, I'm going to change link to delegate to left-only and right-only variants of link. This better represents what's going on, i.e. link never switches directions. I've thought about this but didn't have a good reason to touch the code before.
The text was updated successfully, but these errors were encountered:
There are significant improvements (20-30%) but mostly in benchmarks where the two trees don't have a large intersection (and thus the operation is pretty fast anyway), and less (3-5%) otherwise. I'll try to understand this better before making a PR.
I'm seeing some decent improvements in
union
,difference
, etc. on inlining the no-rebalance Bin-Bin case oflink
containers/containers/src/Data/Map/Internal.hs
Lines 4019 to 4025 in 82c21f0
This is just like #1053, that the common case is one where no balancing is required, and making sure that's fast pays off.
I'll prepare a PR for it.
While I'm here, I'm going to change
link
to delegate to left-only and right-only variants oflink
. This better represents what's going on, i.e.link
never switches directions. I've thought about this but didn't have a good reason to touch the code before.The text was updated successfully, but these errors were encountered: