luri ron wrote:how many listeners you have in the structure for your performance test?
I was running general iteration tests. The tests begin with 10,000 elements and with additions could grow from there.
the search time a list is O(n) compared with skiplist is O(log(n)) which is faster for removal and search.
If a large portion of your application is spent searching and removing data, then yes, you would be better with a sorted collection rather than one where order is maintained on insertion order and searches are linear (Lists). Choose the right collection for the job.
in term of duplicate, it is probably better not to have duplicated listener?
For listeners I generally agree, but I usually let the client determine that behavior, so I use a List since it doesn't impose any limits (for the most part I think the Swing components and default implementation of Bean property listeners also use lists). I don't necessarily think the List is a better approach than a Set, just the one I use...
Anyway, the Listeners is a simple example. But the List interface exists for those cases where duplicates are allowed to exist, and/or insertion order is needed. A lot of heavy data maintenance applications fall into this category (whether it is keeping other apps/clients up to date on current information, distributing work to multiple clients, then pooling the results together, or any situation where the collection is considered a 'data' source only ...)
The point is that the choice between a List and a Set is distinct and independent of the choice between concurrent/thread safe or not, and if concurrent then what type of synchronization works best. The first choice (List or Set) should be based on:
1) Duplicates allowed?
2) Ordering requirements? (including considerations for searches, removals, etc...)
Then choose within the List/Set family to choose synchronization based on expected/measured usage.
And like I said, real world examples are much more complex than any speed test. You can manage an initial decision based on relevant speed tests. Then implement and do your own benchmarks to compare speeds in situations closer to your needs.
I suspect the 'advantage' to the COWAL is that niche where you need a collection that is :
1) A List
2) Accessible by multiple Threads (probably best-case for multiple reading threads with few writing threads)
3) High performant Reads that consume more program time (either because they take longer or occur more often) than modifications
4) Infrequently modified, or modifications can be accumulated to use the bulk (addAll(...), removeAll(...)) operations
5) Eays to use, you don't want to worry about implementing your own Locking system (which could probably be made to outperform COWAL in some cases, but require more work and would be more prone to error).
The ConcurrentSkipListSet seems to work similarly, except the collection is:
1) A Set
2) Accessible by multiple Threads (no knowledge of balance between Read vs Write threads)
4) Possibly frequently modified, but Reads don't necessarily need to include the recent changes
send notification in order is an advantage for the list, but in a distributed environment. this has a lot to do with the network rather than what order the listeners are stored in.