ConcurrentDictionary offer constant read time. I do not need key-value pairs, only keys.. I searched for read times on ConcurrentBag and havent found how it is implemented?
Is there a constant read time ConcurrentCollection, besides ConcurrentDictionary?
ConcurrentBag is probably not what you are looking for:
Represents a thread-safe, unordered collection of objects.
Which means that it allows duplicates (whereas the dictionary doesn't)
Bags are useful for storing objects when ordering doesn't matter, and unlike sets, bags support duplicates.
As for performance, it certainly isn't as much performant as a list (so at least O(n)) (C# - Performance comparison of ConcurrentBag vs List)
For a ConcurrentSet check your luck with the custom implementation here: How to implement ConcurrentHashSet in .Net
You can also check the list of Concurrent collections to see if something else suits your needs.
Related
When using List.AddRange(), is there any difference in performance between adding a List or Array.
MyList.AddRange(MyArrayof1000ComplexElements);
VS
MyList.AddRange(MyListof1000ComplexElements);
or is there no difference?
Since an array and a list both implement ICollection<T>, it uses the same code.
It resolves to a call to Array.Copy(...)
http://referencesource.microsoft.com/#mscorlib/system/collections/generic/list.cs#e569d850a66a1771#references
There is no difference between List<T> and T[] - AddRange uses the same handling for anything implementing ICollection<T>, which both of those do.
Both Array and List implement the ICollection<T> interface. Therefore, the implementation of List.AddRange that is used will be identical and will offer the same performance.
In the future, you can either test something like this yourself with a simple program using the Stopwatch class for timing or download a tool like JetBrain's dotPeek to inspect the framework code yourself.
This is a more interesting question than some of the comments might suggest.
As it happens, for this specific list/array implementation the answer is: no difference. Both rely on the same collection interface.
But it doesn't have to be that way. If a list is implemented as a doubly-linked list (which it is in many other cases) then appending one list to another is O(1) while appending an array to a list is O(n).
And I would not start by benchmarking to resolve this question. Benchmarking is time-consuming to do well and can easily produce results susceptible to misinterpretation. In this case a careful study of the implementation and the underlying source code (easily available through a .NET disassembler) will answer the question faster. Then benchmark to confirm, if it matters enough.
Please note that the specific O(1) optimisation that applies here is only available if MyListof1000ComplexElements too is a List. If it some kind of enumerator or linked list then the performance will be O(n).
In response to those who have criticised this answer, please note that it has been written with the intention of highlighting that the other answers given are based on a specific interpretation of the question. They fail to point out how narrowly they have interpreted the question and how narrowly their answers apply. Another reader might easily miss the fact that this answer only applies to this specific circumstance if they don't say so. My aim is simply to point out that in many other closely related situations, this is an O(n) operation rather than O(1).
What is difference between ImmutableArray<T> and ImmutableList<T>, and where would it be best to use each?
Here is some reading that might help explain: Please welcome ImmutableArray
Here's an excerpt:
Reasons to use immutable array:
Updating the data is rare or the number of elements is quite small (<16)
you need to be able to iterate over the data in performance critical sections
you have many instances of immutable collections and you can’t afford keeping the data in trees
Reasons to stick with immutable list:
Updating the data is common or the number of elements isn’t expected to be small
Updating the collection is more performance critical than iterating the contents
I think you are asking where to use each of them. Please welcome ImmutableArray will help. To summarize, use immutable array when:
Updating the data is rare or the number of elements is quite small (<16)
You need to be able to iterate over the data in performance critical sections
You have many instances of immutable collections and you can’t afford keeping the data in trees
Use immutable list when:
Updating the data is common or the number of elements isn't expected to be small
Updating the collection is more performance critical than iterating the contents
The main difference is that an ImmutableArray is just a wrapper around a normal array, which means that retrieving elements within the array is extremely quick.
An ImmutableArray is also a struct, meaning that it's a value type, so it takes up less space than an Immutable List which is a reference type.
For these reasons, an ImmutableArray is suitable to use if you rarely need to update its data, or the number of elements is small (less than 16), or if the performance of iterating over the collection is important.
If your needs do not match the reasons above, you should use an ImmutableList.
Look here for the documentation.
Going by the blog post "Please welcome ImmutableArray<T>" (the same blog post everyone else is referencing), the differences are...
ImmutableArray:
Simple implementation (just an array).
Not optimized for quickly updating large collections (the entire array needs to be copied).
More efficient for most use cases (anything that does not involve updating large collections).
ImmutableList:
More complicated implementation (something involving trees).
Is optimized for quickly updating large collections (it can be done in logarithmic time).
Less efficient for most use cases.
So if you're not updating much, or your collections are small, use ImmutableArray. If you're going to be frequently updating large collections, you'll need to use ImmutableList.
I have been asked to revise the code written some time ago for a windows form application. The programmer has used ArrayList heavily. I think generic lists are way more efficient compared to array lists and plan to rewrite the code using List<T> I wanted to know if there are any other alternatives that might also be worth considering. I work on .net 2.0
If you're working in .NET 2, then you won't have any of the concurrent collections in .NET 4 available to you, which pretty much just leaves List<T> in terms of "collections which are a bit like ArrayList. (Even within the concurrent collections, there isn't an immediate equivalent - and you should only use the concurrent collections when you actually anticipate concurrent access anyway.)
There are Stack<T> and Queue<T>, as well as LinkedList<T> - but all of those are somewhat different to ArrayList in terms of what you can do with them. They're worth considering if you don't need random access, of course.
I wouldn't expect too much more in terms of efficiency unless you're currently boxing a lot of large value types in your ArrayList. What you can expect is far clearer code. Fewer casts, less uncertainty about the contents of the collection, etc.
If you have the option of upgrading to .NET 3.5 at any point in the near future, that would then give you access to LINQ, which is fabulously useful when dealing with collections. Relatively few new collection types, but much simpler ways of expressing operations on them.
Update:
For add to/remove from head/tail it is better to use LinkedList<T>, but if you can determine exact maximum capacity of collection and size will be close to capacity then may be it's better to use Queue<T> (because internally it's array, reallocated when size reaches capacity). With Queue you will not get memory overhead that comes with LinkedList nodes.
Original:
From MSDN: The List<T> class is the generic equivalent of the ArrayList class.
Please, read carefully List<T> Performance Considerations section.
What should you use depends on how ArrayList is used? Is it random access or add to/remove from head/tail?
Try SortedList and Collection.
Both supported by .NET Framework 2.0
I have a requirement of using a dictionary in the project but as we know that they are only accessible using the keys and not using the indexes, and I want to access the items in dictionary using indexes. So I fiddle over the web and found out about OrderedDictionary as they are accessible using both the indexes and keys but they have some performance issue and as I am reading/writing the dictionary every minute of the day so it's not a good idea to use OrderedDictionary.
So lastly my question in here is that is there any alternative available which gives me functionality of Dictionary and I can also access it using indexes and doesn't cause a performance issue.
SortedList<TKey, TValue> has a property, Values, that is an IList<TValue>. Is it enough? It's fast only for small "sets" of elements. The difference with SortedDictionary is here http://msdn.microsoft.com/en-us/library/5z658b67(v=vs.80).aspx
Can I ask you why you want to access it "by index"? You can still enumerate it with foreach, you know?
in response to your comment that you are only expecting a hundred updates a minute, this is very little work - practically nothing. You can still use an OrderedDictionary, performance will not be an issue for you.
Try SortedDictionary
http://msdn.microsoft.com/en-us/library/f7fta44c.aspx
This question already has answers here:
C# Binary Trees and Dictionaries
(6 answers)
Closed 9 years ago.
I am in the middle of developing a custom persistent Key Value type data structure, to compare against SqlLite and Berkley DB. Anyway before I wrote the implementation I wanted to find the best data structure to use for this purposes. I looked at the a couple:
An open source redblack tree.
Mono Dictionary implementation.
I wanted the datastructures I picked to have performance numbers comparable to the .net dictionary.
I used a simple test for loop with 500k iterations for inserts and used the stopwatch to measure inserts and key look up:
I notice that
Berkley DB key lookup time was about the same as the Dictionary.
I tried my for loop test for C5 the dictionary, a redblack tree implementation and even mono's dictionary implementation.
Insert time: 7% slower than the .net dictionary.
Lookup time: 1000% slower than the .net dictionary. This is even slower than the look up speed with sqllite!! I attempted to perform the test with compiler optimization turned on and still got similar results.
I realize I am comparing Hashtables vs trees etc, but I stumped as to the performance discrepancy between all the data structures.
Anybody have any ideas
Two thoughts:
You should make sure you are not inadvertently including JIT time in your tests - this can add a considerable amount of time to the result. You should perform two runs in the same execution and discard the first run.
You should make sure that you are not running under the debugger - this can dramatically skew performance results.
Aside form that, any performance differences you see may very well be the result of the difference in performance between a hash table and a tree. A tree structure typically has O(n*log(n)) performance on average for a lookup. A balanced tree can reduce that to O(lon(n)). Hashtables, meanwhile, can approach O(1) time for lookups when hash collisions are avoided.
I would also imagine that the .NET Dictionary class is highly optimized since it is a bread-and-butter data structure for so many different things in .NET. Also, a generic Dictionary<> may be able to avoid boxing, and therefore you may see some performance differences from that.
If all you need is a lookup, a red/black tree will not be your best data structure. It provides sorting, which is always going to be slower than a hashtable lookup. If you want to compare .net Dictionary with a comparable C5 data structure, you would use C5.HashDictionary.
Choose the data structure and repository depending on the data. That said, there is no perfect data structure. While the .NET Dictionary<,> is well optimized because it is often a good choice, it is not the answer to all problems - that would be 42...