Share via

ObjectSpaces' performance requirements

  • Article

"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.

Comments

  • Anonymous
    November 06, 2003
    Can you further explain what you mean by a 'merge join' ? How many sql statements will OS submit in that case?
  • Anonymous
    November 07, 2003
    The comment has been removed
  • Anonymous
    November 07, 2003
    Thanks for clearing that up. You guys got some great stuff coming up, but why so late? The majority of .NET acceptors already made significant investments in or-mapping technology. Let alone the companies filling the gap.
  • Anonymous
    November 08, 2003
    ::The majority of .NET acceptors already made significant investments in or-::mapping technology. Let alone the companies filling the gap.Very interesting statement. As a matter of fact in my last session with our lawyers (which we just do every couple of months - you always have to clear things up, have them go over the standard contracts etc.) I was advised that there could be some potential ways heading in MS' directions.We DO have ourselvs significant investments in O/R technology, offering one of the better frameworks in the market. Interesting enough this is an investment I am not yet determined to write off. I know a lot of other companies in a similar position.Interestingly enough, compared to the Java camp (JDO) where the persistence layer was defined as a replacable layer, MS has actually integrated everything in such a way that replacing is not an option.I do smell a "coming late and then destroying competitiors" here. Isn't this what happened to our little friends at Netscape, sort of? Hm. Any of our "competitors" having an for some legal intervention to actually have MS NOT destroy other companies using a monopoly :-)Just joking, naturally. At least for now.
  • Anonymous
    November 16, 2003
    Thomas, I don't get your point: you will still be able to use EntityBroker or any other ORM tool for that matter in V2, right? - You still use ADO.NET, .NET Framework and/or other parts of the operating system/environment with no penalty, right? - I don't even see the slightest hint of MS 'forcing' OS onto the developers, not even jokingly...
  • Anonymous
    July 25, 2004
    dianying xia zai:http://www.kamun.com/
    movie down:http://movie.kamun.com/
    mp3 xia zai:http://music.kamun.com/
    engage:http://club.kamun.com/