Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider addAll special cases #154

Open
chuckjaz opened this issue Oct 25, 2023 · 1 comment
Open

Consider addAll special cases #154

chuckjaz opened this issue Oct 25, 2023 · 1 comment

Comments

@chuckjaz
Copy link

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.

@develar
Copy link

develar commented Oct 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants