Now i watch results on and see that DataObjects.NET is slaughtered by BLToolkit in most of the performance tests. Do you know on which version of DO was these tests running? And if you make something to beat the BLToolkit in some (or all) of these tests? Just curious.

Update: I found that version is v4.1 RC.

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Jun 02 '10 at 11:06

Peter%20%C5%A0ulek's gravatar image

Peter Šulek

One Answer:

Yes, it's slower - and it will be hard to beat it:

  • BLToolkit doesn't provide any tracking on materialization, so you always get new objects when the query is executed. If two queries return the same object, there will be two copies of it. Tracking on materialization implies significant amount of work: keys must be materialized, at least one disctionary lookup should happen to get the existing entity (if any), extracted entity state must be either saved by some way (e.g. as shallow copy), or there should be something like our DifferentialTuple exposing original state + diffs to it, and this isn't all. This is definitely much more complex then invocation of a set of property setters via cached delegates (one dictionary lookup is ~ 15-20 times slower then delegate invocation).

  • It also doesn't track\detect the changes. You must manually ask it to perform exactly the action you want. See - it makes everything clear.

  • There is a special API for batching sequences of either inserts, updates or deletes. See - btw, it was developed right after they have implemented tests for ORMBattle. Generally, we prohibit this ( ), but since everything in BLToolkit behaves this way, we decided to accept this ;)

So BLToolkit is an example of extremally simple API with its pros (speed and simplicity) and cons (no "uniqueing", lazy loading, change detection, etc.).

We're planning to implement few features allowing DO4 to beat it on CRUD tests, but I hardly believe the same is possible for materialization. May be we'll get this change when full POCO support will be added to DO4 (we almost decided to do this). Deal with such simple objects is the only chance to win here.

Another case we're going to address is implementation of more complex test sequence @ ORMBattle - our implementation of batching shows its full power here. Crazy materialization performance isn't really useful in average application, much more depends on small queries here. Query time, future queries and batching are more important, since we must materialize just 20-30 objects per transaction.

answered Jun 02 '10 at 11:30

Alex%20Yakunin's gravatar image

Alex Yakunin

Alex, thanks for explanation of this. I thought that "the best" is now always "The Best", and you give me arguments that its true at least with this.

(Jun 02 '10 at 11:30) Peter Šulek Peter%20%C5%A0ulek's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA