which approach is out performing the other ?

[tinman]

Hi...

I have the following two code excerpts. It basically reads data froma
dataReader and adds it
to a collection....

Excerpt A:
*******

With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"), DateTime), _
DirectCast(.Item("end_date"), DateTime), _
DirectCast(.Item("priority"), Integer), _
DirectCast(.Item("description"), String), _
DirectCast(.Item("project_manager"), String)
End While
End With
Excerpt B:
********

[William Ryan eMVP]

YOu didn't post anything with B to compare to. In general, you want to use
indexes though.

Me.Add(.Item("project_id"))

instead use Me.Add(Item(0))

You can use DataReader.GetOrdingal outside of the While loop which will let
you use a readable name but still use the indexes....if you use strings for
the columnames, they need to be resolved over and over again.

Bill Vaughn recommends using an enum which even cuts out the overhead of
GetOrdinal.
"tinman" <dw****@yahoo.com> wrote in message
news:Ob**************@tk2msftngp13.phx.gbl...

Hi...

I have the following two code excerpts. It basically reads data froma
dataReader and adds it
to a collection....

Excerpt A:
*******

With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"), DateTime), _
DirectCast(.Item("end_date"), DateTime), _
DirectCast(.Item("priority"), Integer), _
DirectCast(.Item("description"), String), _
DirectCast(.Item("project_manager"), String)
End While
End With
Excerpt B:
********

[Jay B. Harlow [MVP - Outlook]]

Tinman,
In addition to William's comments.

Using the DataReader.Get*Type* methods are easier then using DirectCast. The
Get*Type* methods require the ordinal, you can use either GetOrdinal before
the loop, or define an Enum if you know the specific fields returned.

Something like:

Enum Field
project_id
start_date
end_date
priority
description
project_manager
End Enum

Me.Add(.GetGuid(Field.project_id)), _
.GetDateTime(Field.start_date)), _
.GetDateTime(Field.end_date)), _
.GetInt32(Field.priority)), _
.GetString(Field.description)), _
.GetString(Field.project_manager))
David Sceppa's book "Microsoft ADO.NET - Core Reference" from MS Press is
both a good Tutorial on ADO.NET plus an excellent desk reference once you
know ADO.NET.

Hope this helps
Jay

"tinman" <dw****@yahoo.com> wrote in message
news:Ob****************@tk2msftngp13.phx.gbl... Hi...

I have the following two code excerpts. It basically reads data froma
dataReader and adds it
to a collection....

Excerpt A:
*******

With ProjectData
While .Read
Me.Add(DirectCast(.Item("project_id"), Guid), _
DirectCast(.Item("start_date"), DateTime), _
DirectCast(.Item("end_date"), DateTime), _
DirectCast(.Item("priority"), Integer), _
DirectCast(.Item("description"), String), _
DirectCast(.Item("project_manager"), String)
End While
End With
Excerpt B:
********

[Cor Ligthert]

Hi Bill,

YOu didn't post anything with B to compare to. In general, you want to use indexes though.

Me.Add(.Item("project_id"))

instead use Me.Add(Item(0))

You can use DataReader.GetOrdingal outside of the While loop which will let you use a readable name but still use the indexes....if you use strings for the columnames, they need to be resolved over and over again

I respectfully do not agree.

When this becomes an issue you should direct stop using OOP.

It has nothing to do with OOP, however OOP gives also a small amount of
overhead comparing that by writting direct commands. The overhead is direct
in the memory and processor area, and from an ammount, which is probably
1000000000000000000000000 times less than one long mouse stroke.

Just my opinion.

cor

[Cor Ligthert]

Hi Jay,

I respectfully do not agree. See my comments with Bill when you do want to
react, I wrote it at Bill with you in mind..

Cor

[William Ryan eMVP]

Cor, I'm not following you here. If you use GetOrdinal, you can use a clear
name and have Index based lookups. If you use an enum you can use the same
name and still have index based lookups. So you get all the clarity, but
don't have to take the performance hit.

I don't see what you have to loose by using

int project_id = myDataReader.GetOrdinal("project_id")
or
enum myProject
project_it = 0
end enum

and me.Add(.Item(project_id))
or me.Add(.Item(project_id)) 'w/enum

or me.Add(.Item("project_id")

from a maintainability point of view, it's virtually identical, but it
performs a lot better, particularly on large datasets.

Maybe I misunderstood your point or do you disagree with this ?
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:OY**************@TK2MSFTNGP11.phx.gbl...

Hi Bill,

YOu didn't post anything with B to compare to. In general, you want to use

indexes though.

Me.Add(.Item("project_id"))

instead use Me.Add(Item(0))

You can use DataReader.GetOrdingal outside of the While loop which will

let

you use a readable name but still use the indexes....if you use strings

for

the columnames, they need to be resolved over and over again

I respectfully do not agree.

When this becomes an issue you should direct stop using OOP.

It has nothing to do with OOP, however OOP gives also a small amount of
overhead comparing that by writting direct commands. The overhead is

direct in the memory and processor area, and from an ammount, which is probably
1000000000000000000000000 times less than one long mouse stroke.

Just my opinion.

cor

[Jay B. Harlow [MVP - Outlook]]

Cor,
Its your right to not agree!

However as Bill indicated, I'm not following your reply to Bill. Using the
Ordinal or the name has nothing to do with OOP, it has to do with how the
DataReader class was implemented. Looking up the item based on the string is
generally slower then looking up the item based on the ordinal position
(with a DataReader). This is documented in Sceppa's book and I believe Bill
Vaughn has also documented it.

About the only time I see using the name lookups is when you have Option
Strict Off, which itself has benefits & pitfalls. For me Option Strict On is
the better way to go...

Just a thought
Jay

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:Ov****************@TK2MSFTNGP09.phx.gbl...

Hi Jay,

I respectfully do not agree. See my comments with Bill when you do want to
react, I wrote it at Bill with you in mind..

Cor

[William Ryan eMVP]

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:um****************@TK2MSFTNGP09.phx.gbl...

Cor,
Its your right to not agree! Absolutely, and it makes the NG's a better place
However as Bill indicated, I'm not following your reply to Bill. Using the
Ordinal or the name has nothing to do with OOP, it has to do with how the
DataReader class was implemented. Agreed

Looking up the item based on the string is generally slower then looking up the item based on the ordinal position
(with a DataReader). Not generally, always. Its only a matter of how much. And the same holds for datatables too.
This is documented in Sceppa's book and I believe Bill Vaughn has also documented it. Yes, and Bill is quite vocal on this, that's why he came up with the enum
method...to avoid the overhead of using GetOrdinal..so you get the best of
both worlds witha maximum of performance
About the only time I see using the name lookups is when you have Option
Strict Off, which itself has benefits & pitfalls. For me Option Strict On is the better way to go...
Option Strict Off is a Crime against Humanity. It's a tragedy it's not On
by default. Many more pitfalls than benefits...out of curiosity, are there
any other benefits? Other than the same ones you get by turning off option
explicit?
Just a thought
Jay

Cheers,

Bill "Cor Ligthert" <no**********@planet.nl> wrote in message
news:Ov****************@TK2MSFTNGP09.phx.gbl...

Hi Jay,

I respectfully do not agree. See my comments with Bill when you do want to react, I wrote it at Bill with you in mind..

Cor

[Cor Ligthert]

Hi Bill,

What I mean is that simplisity is also a benefit. Without even testing I am
sure that a non strong typed dataset will perform better than a typed
dataset.

And although that people prefer the typed dataset, just because it is better
readable.

I am not with those who say you should always to use it.

However that does not mean that I think that there where it is better for
the readability not even to use the datafieldnames or to make constructions
which help you to avoid that.

But I do not agree that it is "Better"

However just my thought about this.

Cor

[Cor Ligthert]

Hi Jay B.

However as Bill indicated, I'm not following your reply to Bill. Using the
Ordinal or the name has nothing to do with OOP,
That is what I started with, however making good compact readable programs
is *one* of the goals of OOP, that does sometimes conflict with the
performance and in that sense I wrote it, while I was saying it had nothing
to do with OOP.

My opinion is that a very few loss of performance sometimes has to be
accepted for better readability. While there are some cases where that is
not when the process is highly repeatable.

However for that it is in my opinion important if it is a processor/memory
or processor/device operation. For the dataset which is in this case in the
first (it does not affect the real reading) I cannot find any reason to do
something for performance. (In opposite from that I am always saying that it
is in my opinion it is wise to keep it as small as possible, because that is
a processor/device operation)

About the only time I see using the name lookups is when you have Option

Strict Off, which itself has benefits & pitfalls. For me Option Strict On

is the better way to go...

Who wrote that that was not, I do not see the meaning of this sentense in
what I wrote, did I deny that somewhere in this messages.

I thought that with Armin, I am the one who write that the most in this
newsgroup (and I think that the last time I write that even more than
Armin).

:-)

Cor

[Cor Ligthert]

Hi Bill,

I correct my own message, I edited it to many times

And although that people prefer the typed dataset, just because it is better readable. And therefore ...............
I am not with those who say you should always to use it. ................always use it
But I do not agree that it is "Better"

But I do not agree that direct indexing is "Better"

(Although I am that lazy that I often use it in a for indexed loop).

Cor

[William Ryan eMVP]

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi Bill,

What I mean is that simplisity is also a benefit. Without even testing I am sure that a non strong typed dataset will perform better than a typed
dataset.
Actually, the exact opposite is true, but I understand your point.
And although that people prefer the typed dataset, just because it is better readable. and much faster ;-) I am not with those who say you should always to use it.

However that does not mean that I think that there where it is better for
the readability not even to use the datafieldnames or to make constructions which help you to avoid that.

But I do not agree that it is "Better"
Ok, but in the above example, you could have it both ways, readable and
speed. You have a great point, it's just that in this case, there's not a
trade off. If there were, yes, I'd agree with you.
However just my thought about this.

Cor

[William Ryan eMVP]

Ok, but what about using GetOrdinal or the Enum. It's just as readable, the
only thing is Columname vs. "ColumnName" that's only two qoute marks. But
you get much more speed with the ColumnName if you used an Enum or
GetOrdinal.

Wouldn't you also agree that customers decide if they can live with the
performance? A lot of times things perform well in test, then get out in
the field and get sluggish once the DB for isntance, starts filling up.
Then you need some serious rework in many instances. I think you cna strike
a balance, and in this case, you can have it both ways using indexes ;-)

But this certainly isn't the case most of the time, in those instances, I
totally agree with you.
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:Oa**************@TK2MSFTNGP09.phx.gbl...

Hi Bill,

I correct my own message, I edited it to many times

And although that people prefer the typed dataset, just because it is

better

readable.

And therefore ...............

I am not with those who say you should always to use it.

...............always use it

But I do not agree that it is "Better"

But I do not agree that direct indexing is "Better"

(Although I am that lazy that I often use it in a for indexed loop).

Cor

[Cor Ligthert]

>

Actually, the exact opposite is true, but I understand your point.

Do you mean because the adapter.fill is not used in that when it is made by
the designer?

Cor

[Jay B. Harlow [MVP - Outlook]]

Bill,

About the only time I see using the name lookups is when you have Option
Strict Off, which itself has benefits & pitfalls. For me Option Strict

On is

the better way to go...
Option Strict Off is a Crime against Humanity. It's a tragedy it's not On
by default. Many more pitfalls than benefits...out of curiosity, are

there any other benefits? Other than the same ones you get by turning off option explicit?
Option Strict Off allows Late Binding, Late Binding is a form of
Polymorphism, Polymorphism can simplify your programs. Smalltalk is
effectively all late bound polymorphism.

Late Binding also simplifies some COM interop code, for example the CDO
1.2.1 class library was designed with VBScript in mind, in VBScript every
thing is an Object & every thing is Late Bound. Seeing as every thing is an
Object, all the properties in CDO 1.2.1 are Object (not strongly typed). If
you use CDO 1.2.1 from VB.NET or C# you need to cast all the properties into
strongly typed variables or rely on late binding.

Normally I have Option Strict On & Option Explicit On explicitly stated in
each source file, I do not rely on project options or VS.NET options. If I
need to use Late Binding (Option Strict Off) as for example I have a lot of
CDO 1.2.1 code then I will encapsulate that in a single class and have that
class file explicitly Option Strict Off.

Note using a healthy dose of DirectCasting you can use CDO 1.2.1 with Option
Strict On, however the code is harder to read...

Hope this helps
Jay

"William Ryan eMVP" <do********@comcast.nospam.net> wrote in message
news:ur**************@tk2msftngp13.phx.gbl...
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:um****************@TK2MSFTNGP09.phx.gbl...

<<snip>>

[William Ryan eMVP]

No, referencing anything with a Strongly typed dataset is much faster b/c
it's typed. Just like Option Strict On vs. Off.
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:eH**************@TK2MSFTNGP10.phx.gbl...

Actually, the exact opposite is true, but I understand your point.
Do you mean because the adapter.fill is not used in that when it is made

by the designer?

Cor

[Cor Ligthert]

Hi Bill,

No, referencing anything with a Strongly typed dataset is much faster b/c
it's typed. Just like Option Strict On vs. Off.

This would implied for me that the dataadapter.fill from a strongly typed
dataset would read the schema and from a non strongly typed dataset not.

You know that that is not true.

However I think it is better to make this thread OT otherwise we go to far
in it.

It is not a religion or something.

Cor