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
When a PersistentVector<T> is added to another PersistentVector<T> through addAll this can be optimized and, when the shift alligns, layers of the vector, as a whole, can be copied over instead of copying individual elements. Even if the shifts don't allgin, copyInto can be used instead of going through the addAll of the builder which can avoid several otherwise unncessary allocations and virtual dispatches.
A similar technique can be used for the TrieNode for the PersistentHashMap but the special cases end up not being nearly as rare as it will often be the case when whole TrieNodes can be copied from one PersistentHashMap to another.
The text was updated successfully, but these errors were encountered:
Yes, this is quite essential. For instance, the IJ Platform uses this for the implementation of extensions. A pattern like "get all extensions and merge with another one" is quite popular. If it will behave as described above, it will provide a good reason to prefer the kotlinx collections library over the Java immutables one.
When a
PersistentVector<T>
is added to anotherPersistentVector<T>
throughaddAll
this can be optimized and, when the shift alligns, layers of the vector, as a whole, can be copied over instead of copying individual elements. Even if the shifts don't allgin,copyInto
can be used instead of going through theaddAll
of thebuilder
which can avoid several otherwise unncessary allocations and virtual dispatches.A similar technique can be used for the
TrieNode
for thePersistentHashMap
but the special cases end up not being nearly as rare as it will often be the case when wholeTrieNode
s can be copied from onePersistentHashMap
to another.The text was updated successfully, but these errors were encountered: