ORMBattle.NETThe ORM tool shootout

  • Increase font size
  • Default font size
  • Decrease font size
Home FAQs CUD tests are, in fact, designed for ORM tools using batches there. Why do you think this honest?

CUD tests are, in fact, designed for ORM tools using batches there. Why do you think this honest?

E-mail Print PDF

Yes. This is right, if ORM bakes decision about batching by its own - this neither limits the users by any way nor makes them to worry about this. The only effect of such batches is improved performance, and of ORM tool A can utilize this feature, but ORM tool B can not, ORB tool A will be almost surely better on CUD test.

Ok, but is this important? You can find that yes, this is. This feature reduces chattiness between ORM and RDBMS by 20-30 times. Some numbers:

  • Almost any communication protocol is limited by ~ 10...30K request-reply cycles per second per single thread (can someone add some references here?)
  • Index modification performance is higher than 100K records per second, while its changing pages are cached in memory. Table is ~ primary index + a set of secondary indexes.

This means that if we'll send CUD commands separately, we'll loose 1/20...30K of second per each of them just for unnecessary communications; actual time spent on index modifications per each of such commands will be likely even smaller. Thus such an optimization may reduce the average CUD time by 2-3 times, and this is clearly visible on tests. Moreover, it will reduce network load and eliminate a part of unnecessary load from the communication stack.

Think about this:

  • Normally application updates multiple objects per transaction. Especially in OLTP.
  • The number of such objects can differ from just few (frequently) to hundreds (rarely).
  • Likely, such operations "eat" the most part of time spent on data modification. Obviously, there can be other data modification operations, e.g. running as stored procedures or executable DML queries. But normally they are rare (e.g. performed on daily\hourly basis during bulk data import and so on).

So we believe CUD sequence batching (and batching in general) is a must-have feature for any contemporary ORM. And that's why our tests allow to utilize it.

Note: there are "CUD Single" tests as well - they're especially designed to prevent utilization of this feature. Together with "CUD Multiple" they provide a complete picure of CUD performance.

Last Updated on Thursday, 20 August 2009 09:42  

Polls

Which test must we add next?
 

Subscribe to our blog