Share via

What's under the hood? [Ariel Weinstein]

  • Article

Well, I tried to solicit email from you with any cool ideas you have for Collections, ServiceProcesses, and Diagnostics, but that front has been a bit quiet. Thats quite ok though, because there is something else I would like to touch on today. My main roles right now are those three features, as well as application compatibility between different versions of .Net. Luckily, an issue came up this week that covered both areas very nicely.

I received an email where somebody was trying to understand exactly how ListDictionary works. Specifically, ListDictionary is implemented with a list, and the person wanted to know if objects are placed in the front or rear of the list. After talking with other members of the development team, we decided the answer is that it isn't really useful to document how it is implemented. The reason behind it is that people may start using this information to write code that uses behavior that currently works but is not guaranteed to work (you wouldn't do that though, right?).

For example, somebody might want to test if a key was added to the dictionary. If that person knew that the key was placed at the front of the list, they do something very unwise such as checking the first object in the ICollection returned by ListDictionary.Keys to make sure the last Key was entered. This operation _may_ work if the implementation is done in a certain way, but has little to do fundamentally with how a dictionary is intended to work, which means it could be changed in a later version of the software if the current implementation turns out to be broken/slow/whatever.

So to sum up? If you are trying to figure out how something such as a collection is implemented under the covers, it may be appropriate to try using a different collection altogether. For the question above, it may be much better for the user to simply use a List to ensure that functionality.

However, if you think the documentation is sparse, please send drop a comment here I'm still waiting for some from last week's post!

-Ariel
ArielW@microsoft.com

Comments

  • Anonymous
    August 05, 2005
    My thoughts are that the documentation should include the algorithmic complexity of a particular operation. For example, I might not need to know exactly how a particular operation is performed, but I would like to know what the cost might be to use a particular function. There are many libraries (the C++ STL comes to mind) that does a fairly good job of providing such information.
  • Anonymous
    August 05, 2005
    +1 to describe asymptotic behaviours for memory and speed.

    Also could please describe the reasons for such a small set of collection classes?
  • Anonymous
    August 06, 2005
    Collections are my biggest pet peeve with .NET. :) I've posted my views on collections at http://aspnetresources.com/blog/dotnet_collection_madness.aspx and http://aspnetresources.com/blog/dotnet_collection_madness2.aspx.
  • Anonymous
    August 08, 2005
    I agree with jgalla. Often I want to have an idea of the algorithm used internally, not because I really want to know how it works, but because I want to have an idea of how fast a particular method works. Since most of these algorithms are not documented, I currently use reflector to learn what I want to know.
  • Anonymous
    August 08, 2005
    I agree, I often have to come up with a working solution just to test the performance of a collection/etc because there is no documentation on performance/algorithms are used. I've sometimes used reflector to dig through the code to figure out what is going on. Either way, not a fast way of gleening this information.
  • Anonymous
    August 20, 2005
    Cool Ideas for the Collections API:

    1. A performant dictionary that maintains insertion order (cough java.util.LinkedHashMap cough).
    2. A performant dictionary that maintains sort order (cough java.util.TreeMap cough).