I have seen some articles, but IIRC they were Microsoft internal and not for
outside consumption. I wrote some benchmarks myself and included these in my
book (see web site). Generally they showed that ADO classic and ADO.NET ran
at about the same speed and they both waited at the exact same speed. In
some cases ADO.NET was unable to complete the operation due to missing
functionality, but the same can be said for ADO classic. Consider that the
two interfaces are very, very different and although they are designed to do
roughly the same thing (in most respects), they do so in entirely different
ways. In some respects, ADO.NET is far lighter in functionality (it does
less FOR you and less TO you) but far broader in functionality in other
areas. For example, ADO.NET exposes the low-level data stream for the first
time since DB-Lib. It is not dependant on COM or OLE DB (unless you're stuck
with JET).
It also turns out that in most cases, an application's speed is not a
function of how well you ask the question with ADO (or ADO.NET) but how
efficiently the backend can answer the question (how smart was the
question). A good index or selecting fewer rows can do more to help
performance than picking the right execution style in ADO.
hth
--
____________________________________
Bill Vaughn
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
