[ZODB-Dev] IIBTree.multiunion and list comprehensions

[Tim Peters]

[Christian Robottom Reis]
> ...
> I'm wondering why multiunion creates IISets instead of
> IITreeSets, though.

It was by far the best approach for the use case that drove multiunion's
addition.  Several partial search results needed to be united, to drive a
result display.  The output only needed to exist for as long as it took to
display the result (or to feed into another operation in the same overall
search, like an intersection), so persistence friendliness wasn't a goal.
The output was expected to be temporary, in-memory, and short-lived.

A one-shot in-memory IISet is more efficient (both in storage size and in
time to iterate) than a one-shot in-memory IITreeSet, and the implementation
of multiunion *naturally* produces a sorted contiguous vector of integers
anyway.  It would take more time, and twice the memory, to bust it up into
an IITreeSet's multiple buckets.  Neither persistence nor the good log-time
insert and delete behavior of an IITreeSet were wanted in the use case, so
there was nothing to justify the extra expenses of producing one.