views:

500

answers:

2

I am creating a mock database for import export tests (of the algorithm reading and writing complex data structures to our database, not just to test IO operations), and am trying to decide whether to use a DataSet to store the mock tables (by table name) in the faux-database, or Dictionary()

In terms of retrieving a datatable by name, would I expect better performance from, dataset.Tables["TableName"] or dictionary<"TableName"> (from Dictionary()?

+3  A: 

DataSet.Tables is internally implemented using an ArrayList. Looking up a table by name involves a linear search through the tables in the list and a lot of casting. So using a Dictionary, which is hash-based and generic, would almost certainly be faster. (Although you'd need a lot of tables and/or a lot of accesses for it to make much difference.)

Eric Rosenberger
+4  A: 

Actually, Dictionary<,> is often slower than a linear search, due to the inherent complexities of doing the dictionary logic (haches, buckets, etc). In my tests, the cutoff (where Dictionary<,> starts being faster) is often around 150 elements. And since you generally have a lot fewer tables than 150, I'd be happy with a linear list for performance.

(which doesn't at all mean "don't use Dictionary<T>; it just means that performance might not be the main reason for this particular use-case; the unique key enforcement and the foo["bar"] model might be)

Part of this is due to the complexity of getting the hash - the GetHashCode() for string in particular is relatively expensive (although int.GetHashCode() is blindingly fast ;-p).

In reality, in most small sets of data you will never notice the difference between the two. If you have large data, then obviously you need to plan for that and code accordingly.

Other differences between a Dictionary<,> and something like a List<> is things like uniqueness: a Dictionary<,> won't let you have duplicated keys (although a Lookup<,> in .NET 3.5 will).

Marc Gravell
Very interesting... definitely a caveat worth considering in the future.
Eric Rosenberger