CODEWITHSUNDEEP
c#listobjectdictionarykey-value
Xantham
Xantham

Reputation: 1899

Storing a list of objects and identifying one property as a Key for fast lookup

Lets say I had a List of storyCharacter objects. Each object stores an ID#, name, and favorite color, such as the example below:

ID#   |  Name        |  Favorite Color
21    |  Optimus     |  Blue
29    |  Ironhide    |  Red
34    |  Starscream  |  White

What would be the best way to create a a key-value pair such that it is keyed to the ID#.

I know that I could use a Dictionary, but would

dictionary.Add(storyCharacter1.IDnum, storyCharacter1);

be a good way to do it? I assume that way would make a copy of the ID as the key, and thus use up more memory unnecessarily, since that information is already in the object. Of course, I could just not store the IDnum in the storyCharacter object, and just use it as the key. Since that would create an object with just the name and color, and then be associated with a key of the IDnum, that feels like I'm decoupling data that should stay together.

I could also use a List<>, but then I would have to either foreach and look through, or use LINQ.

So, is there a way to store a list (of some sort) of objects, and identify one element of that object as the key? If not, what alternatives are there to do something similar, and what are they're tradeoffs?

Upvotes: 0

Views: 432

Answers (2)

George Mauer
George Mauer

Reputation: 122232

You're talking about an in-memory datastore which is just...memory.

You ask for the "best way" of doing this but don't specify any conditions. Well, the recommended way of storing a collection of objects in memory is just to use a an array or a List<>. And yes, iterating through it with LINQ. LINQ is very well optimized including some run-time optimizations, it is very unlikely that your use-case is one for which this approach is too slow or uses too much memory.

If your dataset is indeed that large (in which case in-memory seems like a poor choice) and you're concerned about lookup times Dictionary<> is going to give you pretty solid performance.

But perhaps what you want is really something like an object database, consider db4o. Or a document database, consider RavenDb (or monogo,redis,etc) - Raven has an Embedded mode that allows you to run it in-process.

Again, for in-memory stuff this is all pedantic - against even fairly large datasets I have never seen just using the builtin Dictionary<> be a problem.

Upvotes: 1

Matt Greer
Matt Greer

Reputation: 62057

Creating a dictionary like that is a common and perfectly valid way to speed up looking up something. Using more memory to gain more performance is a common trade off.

At most, the dictionary will use 8 bytes per key if IDNum is a double (which I doubt), other than that it will use 4 bytes per key. If IDNum is an object, it won't copy the whole object just a reference to it (which takes up 4 bytes on 32 bit systems).

But ... do you really have memory concerns? Is this on an embedded device or something with low memory? Premature optimization (for both speed and memory) is often a bad thing. I'd go with your overall design and address memory/perf issues later.

Upvotes: 2

Related Questions