From a comment on my “ObjectSpaces Myths” post:


However it's NOT a myth that ObjectSpaces is spec'ed to be 40% slower than DataSets, correct?”


The comparison is actually not that simple.  There are two basic reading from the data store scenarios:  1) Streaming and 2) Filling a cache.


For Streaming, ObjectSpaces goal is to be within 30% of SqlDataReader.  That is if you streamed out the same set of relation data through the SqlDataReader versus the ObjectReader, the goal is to see about a 30% performance difference.  In general, this performance difference comes from the materializing of the objects and some overhead from the mapping layer.  Note – if one was to materialize their own objects over the SqlDataReader, they probably won’t see a significant difference between ObjectSpaces and their custom solution.


For filling the ObjectSet caches with the results of an ObjectQuery, the performance goal is to be on par with filling the DataSet from a SqlDataReader, particularly for hierarchy cases with several levels.


Along the same lines, ObjectSpaces will leverage the MARS support in Yukon .  Therefore for master-detail type queries, the overall performance will tend to be better since the query engine will perform a merge join over the streamed results.  So unless one does a join on the server and then normalizes the results them self, it will be hard to beat the ObjectSpaces’ performance.  As the hierarchy becomes deeper and more complex, this performance gain will be more noticeable.