ObjectSpaces' performance requirements

"urn:schemas-microsoft-com:office:office" />

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.

"urn:schemas-microsoft-com:office:smarttags" />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.