Use ConcurrentSkipListSet instead of CopyOnWriteArrayList for holding state keys #92
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was digging through the code and I a portion that might benefit from more efficient traversal.
Currently,
stateKeys
usesCopyOnWriteArrayList
, presumably in order to iterate the list at that point while also removing entries from the list.dispose
performs a linear search when disposing a screen, filtering all those entries which match the prefix of the screen key.I reckon:
Set
. I've noticed with the master-detail example, clicking an item and going back, that the list was polluted with entries forScreen#0
, which should be conflated (right?).I haven't done a complete implementation for KMM, just want to sketch out the idea and ask if it looks reasonable to you. Perhaps I am overlooking something, like a race condition you're more aware of than I am.
Let me know what you think!