Is IDataReader.GetInt32 more efficient than IDataReader.Item?

  • Thread starter Thread starter Rob Nicholson
  • Start date Start date
R

Rob Nicholson

Hypothetically, is IDataReader.GetInt32 more efficient that
IDataReader.Item, e.g.

Dim MyNumber As Integer = MyReader.GetInt32(0)

Versus

Dim MyNumber As Integer = MyReader.Item(0)

Thanks, Rob.
 
Rob said:
Hypothetically, is IDataReader.GetInt32 more efficient that
IDataReader.Item, e.g.

Dim MyNumber As Integer = MyReader.GetInt32(0)

Versus

Dim MyNumber As Integer = MyReader.Item(0)

the last one will not compile with OPTION STRICT on. When you develop it
correctly:

Dim MyNumber As Integer = CType(MyReader.Item(0), Integer)

it will be the same, as MyReader.GetInt32(0) also performs a cast internally.

Frans.
 
It is more or less the same in terms of speed, however GetInt32 is strong
typed which is a good thing normally :).
 
Frans Bouma said:
the last one will not compile with OPTION STRICT on. When you develop it
correctly:

Dim MyNumber As Integer = CType(MyReader.Item(0), Integer)

it will be the same, as MyReader.GetInt32(0) also performs a cast internally.

Surely that depends on the implementation. There's no *requirement* for
GetInt32() to cast, is there? It'll depend on the exact IDataReader
being used.
 
Jon said:
Surely that depends on the implementation. There's no requirement for
GetInt32() to cast, is there? It'll depend on the exact IDataReader
being used.

Ok, point taken. :) (For the SqlClient at least, it casts :))

FB
 
As many already pointed out, it's more or less the same today. However, we
usually can optimize strongly-typed getters more than the untyped getters in
the future. For example, although we do boxing today for value types even
when you use strongly-typed getters, we won't in the next version. The
difference is small (we save 1 allocation per-value-type column,
per-Read()), but in highly stressed apps it can certainly show.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Pablo Castro said:
As many already pointed out, it's more or less the same today. However, we
usually can optimize strongly-typed getters more than the untyped getters in
the future. For example, although we do boxing today for value types even
when you use strongly-typed getters, we won't in the next version. The
difference is small (we save 1 allocation per-value-type column,
per-Read()), but in highly stressed apps it can certainly show.

I would imagine the difference grows quite large if you're reading a
lot of value types - it could mean the difference between having a load
of garbage collections and not, as each of those boxing operations will
be creating a value which is almost instantly garbage.
 
Yes, that's correct. Also, since we box the value when constructing the
buffer (during Read()), not when the getter is called, the "box object" is
not immediately collected, so it survives post G-0 collection, making the
hit on the GC worse.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top