HybridDictionary v.s. XPath Queries for performance?

[Mark S.]

The app gets about 300 requests per second during peak hours. The part of
the app in question acts like a "lookup table", but isn't tied to a
database. My reading on the subject, and my test code, leads me to believe
using a HybridDictionary object is super fast. Yet I'm told XML parsing is a
contender and should be considered.

In your experience which you would you use, considerations that should be
taken into account and any gotchas you've come across.

Thank you.

 

[Daniel O'Connell [C# MVP]]

The app gets about 300 requests per second during peak hours. The part of
the app in question acts like a "lookup table", but isn't tied to a
database. My reading on the subject, and my test code, leads me to
believe using a HybridDictionary object is super fast. Yet I'm told XML
parsing is a contender and should be considered.

In your experience which you would you use, considerations that should be
taken into account and any gotchas you've come across.

How complicated is your data? Is it just a single key or is it a deep
lookup? If its just a key-value pair lookup, may as well use the dictionary,
I can't say it'll be faster without testing it, but it'll almost certainly
be simplier, and if your tests are showing HybridDictionary is faster, I
can't see any reason to use XML.

 

[Mark S.]

How complicated is your data? Is it just a single key or is it a deep

Good question, I look forward to hearing your thoughts if the answer changes
your opinion...

If I used a HybridDictionary, here's the approach I'm considering.
Keys:
-- the key would be a string no longer than 50 characters in length
-- today the number of keys would be about 40, but could grow to a couple
hundred over the next year or two.

Values:
This is a little tricky. Depending when, who and a couple other criteria the
returned value will change.
-- another HybridDictionary as the value and using a few switches and ifs,
determine which value of this child dictionary should be returned. There's
an outside chance this child might need it's own child dictionary object.

Does this change your thinking or does a better approach come to mind?

 

[Daniel O'Connell [C# MVP]]

Good question, I look forward to hearing your thoughts if the answer
changes your opinion...

If I used a HybridDictionary, here's the approach I'm considering.
Keys:
-- the key would be a string no longer than 50 characters in length
-- today the number of keys would be about 40, but could grow to a couple
hundred over the next year or two.

Values:
This is a little tricky. Depending when, who and a couple other criteria
the returned value will change.
-- another HybridDictionary as the value and using a few switches and ifs,
determine which value of this child dictionary should be returned. There's
an outside chance this child might need it's own child dictionary object.

Does this change your thinking or does a better approach come to mind?

If you are going to have dictionaries of dictionaries, its almost certainly
looking into XML if the data is going to be serialized in any way, not sure
its worth doing if you are never going to actually *serialize* to xml.