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

Backport insertion-ordered immutable map to capsule #5

Open
msteindorfer opened this issue Aug 15, 2016 · 4 comments
Open

Backport insertion-ordered immutable map to capsule #5

msteindorfer opened this issue Aug 15, 2016 · 4 comments
Assignees

Comments

@msteindorfer
Copy link
Member

I previously already implemented an insertion-ordered immutable map for another open-source project. The goal is to backport this implementation to capsule and integrate them into capsule's API.

msteindorfer added a commit that referenced this issue Aug 15, 2016
See issue #2 and issue #5. The current implementation is not yet
complete and still requires rework.
@msteindorfer msteindorfer self-assigned this Aug 15, 2016
@wrandelshofer
Copy link

Hi,

I made an experimental implementation of an insertion-ordered immutable map based on the CHAMP trie in Capsule. It stores elements with sequence numbers in the trie. Its iterators sort the elements with a bucket sort. It uses a large number of buckets (between N and N*4 buckets), so that the sorting can be performed in linear time.

I have benchmarked it against VectorMap in Scala. The performance is better, except for retrieval of the first/last element, which takes linear time in my implementation.

The code and benchmark results are here.
https://github.com/wrandelshofer/vavr#readme

@jurgenvinju
Copy link
Member

this is interesting! What kind of applications do you have in mind typically? Just to get an idea of what we could build on top of this.

@wrandelshofer
Copy link

Well, mostly the following kinds of applications:

  • Real-time monitoring and control systems. The business objects can have multi-valued properties. The property values must be immutable. We can have hundreds of thousands of them per server instance. Currently we use unmodifiable collections and defensive copying. But this is error-prone, and we can not afford errors in this kind of applications. - We need immutable collections that can not throw UnmodifiableOperationException.

  • Data visualisation and modeling tools. The model objects can have multi-valued properties. The property values must be immutable. We can have millions of them, and we must provide an undo/redo history for each of them. - We need immutable collections that we can safely share with many model objects.

  • Graph algorithms. Some of the algorithms work with immutable sets and sequences. Our graphs are directed and may contain cycles. They can have hundreds of thousands of vertices. - For this, we need immutable collections that are performant, and are friendly to the garbage collector. (I am somewhat pessimistic about the garbage collector friendliness of CHAMP tries. Maybe I need to implement something based on the ByteBuffer or the upcoming Java Foreign Memory API instead).

@jurgenvinju
Copy link
Member

👍 yes that sounds good. @msteindorfer do you have time to review @wrandelshofer 's branch? I think we might be able to use his contributions for Rascal as well. What do you think?

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

No branches or pull requests

3 participants