Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have a set of data that I should be able to filter by two keys, which are strings.
So I've been wondering what is the faster way to do it.
The most obvious way is a nested dictionary
Dictionary<string, Dictionary<string, Data>>
but I've been also thinking about either using a tuple
Dictionary<(string, string), Data>
or combining the strings to create a key
string.Format("{0}:{1}", key1, key2)
Dictionary<string, Data>
Now this option I doubt is faster, since every lookup is gonna be coupled with the formatting of the key
There's also the option of creating a struct, which will act as the key
dataKey(key1, key2)
Dictionary<dataKey, data>
Or maybe for such case something else than a dictionary would be a better fit?
In that case I'd add that in the actual application, I first search for key1+key2 combination, and if there's no matching data, I find it using only the key2 and use a placeholder key1.
Nested dictionary lookup is a 2 lookup operations.
If you combine your two keys into one, you will avoid the second lookup operation, at the cost of a new string allocation.
It should be more efficient to have a specific structure as key that contain the two keys, and to implement GetHashCode() and Equals()
But as said by Jeroen, you should write you own benchmarks with tools like Benchmarkdotnet for real figures.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Why would anyone ever use a dictionary with two integers?
It seems to me like this would just create an indexed collection of integers, where the "key" is the integer index and the "value" is the integer.
Or, in other words, it would be the same as a list of integers.
Now, I suppose having a dictionary allows you to set custom integer keys, so for example you could have pairs like (1,2) (7,3), etc. but this still doesn't make much sense. But when would it actually be practical/useful to use a dictionary as opposed to List?
For example, if you have a database-table with customers.
And you have another table with orders.
You want to get the number of different orders of every customer from the database.
Then you could save it as a Dictionary<int, int>, where the first int is the customer's id and the second int is the number of different orders they have.
The TKey (on a Dictionary<TKey, TValue>) is not the index. It is a key value, you do not need to follow a specifique order in the TKey. The TKey is just a value you use to get an excatly item on the dictionary. To access an item of the dictionary by index, you can get the index by keys collections. For sample:
int key = dictionary.Keys.ElementAt(2); // the 3'rd element
var value = dictionary[key]; // the the value by the key
A List<T> is a list of value and you can access by the index.
var value = list[2]; // get the 3'rd element
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm refactoring some legacy code that uses a 2D string array:
/// <summary>Array of valid server messages</summary>
private static string[,] serverRsp =
{
{"JOIN", "RSP" },
{"SETTING", "RSP" },
. . .
I want to modernize this, but don't know if I should use a Dictionary, a List of list of string, or something else. Is there a standard correlation between the "olden" way and the golden way (legacy vs. refactored)?
IWBN (it would be nice) if there was a chart somewhere that showed the olden vs. the golden for data types and structures, etc.
[,] is not an "old" datastructure, and hopefully will never become.
Keep using it whenever appropriate.
For example:
just in this case have a List<List<T>> is much more confusing then having simple 2 dimensional array.
It's lighter then List<T>in terms of memory consumption (at least from my measurements).
In short: if there is no any real reason, or new requirement to change it, like make it faster O(1) access data structure key-value store (for non index, hence key like, fast access), do not change it. It is clear and it is readable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the suggested key, value container where the key is always of type string, and the value is a type? The container will not be larger than 100 items. Thanks!
You should definitely go with standard Dictionary<TKey, TValue>. The only improvement you can make is based on your there will be no more than 100 items condition.
Use new Dictionary<string, MyType>(int capacity) constructor when creating dictionary, it will prevent underlying storage from reallocating when new items are added.
var dict = new Dictionary<string, MyType>(100);
I have trouble suggesting anything other than the standard .net dictionary if you need concurrency there is also a ConcurrentDictionary
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have the choice of where to put both key;
Dictionary<key1, Dictionary<key2, int>>
Dictionary<key2, Dictionary<key1, int>>
if key1 is 32x smaller than key2
which one should I implement to get maximum speed?
does it matter even matter?
is there a better way to implement that?
Probably you get the best performance by implementing a composite key:
struct Key { key1; key2; }
Implement Equals and GetHashCode for it (better yet, the IEquatable<Key> interface).
With this pattern you only need one dictionary and one hash lookup.
so after playing around i went with this solution;
int[,][] myDict;
instead of
Dictionary<int, Dictionary<int, int>> myDict;
or a tuple or struct for both keys
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm writing a service where performance is essential, and I'm not sure what is the fastest thing. I have a few Objects (50-200) which each have an ID in them (ints, e.g. 84397 or 23845). Would it be faster to have a Dictionary, a List of KeyValue Pairs or a List with the indexes set to the IDs with the rest having null values or an array with the same idea?
It depends on which operation you want to execute. Let's assume that you want to find an object with a given ID.
The huge array approach is fastest: Accessing myArray[84397] is a constant-time operation O(1). Of course, this approach requires the most memory.
The dictionary is almost as fast but requires less memory, since it uses a hash table internally.
The list of pairs approach is the slowest, since you might have to traverse the whole list to find your entry, which yields O(n) complexity.
Thus, in your situation, I would choose the dictionary, unless the marginally better performance of the huge array is really relevant in your case.
Dictionary<TKey, TValue> uses a hash table internally so I think it would be the fastest one.
Dictionary versus List Lookup time
Also, for a more detailed explaination of the different collections, check out this question.
You can use Hashtables as well. Dictionary internally using it anyway.
but dictionary has an advantage that it is a GENERIC type which gives you type safety.
here is different thread
Dictionary Vs HashTable
I hope it helps you decide.
Praveen