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 http://goo.gl/pzld - it makes everything clear.

• There is a special API for batching sequences of either inserts, updates or deletes. See http://goo.gl/OBsZ - btw, it was developed right after they have implemented tests for ORMBattle. Generally, we prohibit this ( http://goo.gl/OBsZ ), 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.