3

I am designing a C# class that contains a string hierarchy, where each string has 0 or 1 parents.

My inclination is to implement this with a Dictionary<string,string> where the key is the child and value is the parent. The dictionary may have a large amount of values, but I can't say the exact size. This seems like it should perform faster than creating composite wrapper with references to the parent, but I could be wrong.

Is there an alternative approach I can take that will ensure better performance speed?

smartcaveman
  • 41,281
  • 29
  • 127
  • 212
  • 1
    "better performance" in what respect? Time, space? What are your requirements? How will this be used? What's your worst case? You need to answer these questions before anyone can help you. – Ed S. Jul 04 '11 at 02:27
  • How do you get children for a given parent if you're implementing it this way? – antsyawn Jul 04 '11 at 02:35
  • @eds, Performance with respect to time. I updated the question. – smartcaveman Jul 04 '11 at 02:44
  • @ansyawn, I don't need to get children for a given parent. – smartcaveman Jul 04 '11 at 02:45
  • Then my response should help you. Lookup speed is very fast for a `Dictionary` as long as the implementation of `GetHashCode()` is reasonable, which it is for `string`. – Ed S. Jul 04 '11 at 02:45
  • @eds, Thanks. You're follow up questions made me aware that I am a little bit ignorant about performance. Where can I find some resources about the importance of different performance metrics, and the effects of code on performance metrics? – smartcaveman Jul 04 '11 at 02:47
  • 1
    That;s a great question =). First of all (IMO) you need a basic understanding of how the hardware works. Next you need to be able to determine where your bottlenecks will be. That's where you optimize. There is no sense in spending time optimizing a part of your code that is not a bottleneck and will save you 1 second of execution time over 5 years of execution. Like many things, there is no simple, short answer to this question. It takes time and experience, and an understanding of how things are working (particularly data structures) behind the scenes. – Ed S. Jul 04 '11 at 02:55
  • 1
    So, in short; just keep studying! It comes with time, just continue to learn fundamental concepts as they *are* very important. The high level, abstraction laden stuff is all fine and dandy until you hit something like a performance problem. then you need the knowledge and experience to see through the layers of abstraction and reason about why the code is not performing well. also remember that a good profiler is your best friend. – Ed S. Jul 04 '11 at 02:56

2 Answers2

11

Retrieving values from a Dictionary<K,V> is extremely fast (close to O(1), i.e., almost constant time lookup regardless of the size of the collection) because the underlying implementation uses a hash table. Of course, if the key type uses a terrible hashing algorithm than the performance can degrade, but you can rest assured that this is likely not the case for the framework's string type.

However, as I asked in my comment, you need to answer a few questions:

  1. Define what performance metric is most important, i.e., Time (CPU) or space (memory).
  2. What are your requirements? How will this be used? What's your worst case scenario? Is this going to hold a ton of data with relatively infrequent lookups, do many lookups need to be performed in a short amount of time, or do both hold true?

The Dictionary<K,V> class also uses an array internally which will grow as you add items. Is this okay for you? Again, you need to be more specific in terms of your requirements before anyone can give you a complete answer.

wonea
  • 4,783
  • 17
  • 86
  • 139
Ed S.
  • 122,712
  • 22
  • 185
  • 265
1

Using a Dictionary will be slower than using direct references, because the Dictionary will have to compute a hash etc. If you really only need the parent and not the child's operation (which I doubt), then you could store the Strings in an array together with the index of the parent String.

wonea
  • 4,783
  • 17
  • 86
  • 139
kohlerm
  • 2,596
  • 1
  • 17
  • 22