which approach is out performing the other ?

  • Thread starter Thread starter tinman
  • Start date Start date
T

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:
********
 
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,
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))
Click to expand...

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
 
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
Click to expand...

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
 
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, 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,
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
 
Jay B. Harlow said:
Cor,
Its your right to not agree!
Click to expand...
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.
Click to expand...
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
Click to expand...
much. And the same holds for datatables too.


This is documented in Sceppa's book and I believe Bill
Vaughn has also documented it.
Click to expand...
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...
Click to expand...

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?
 
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
 
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,
Click to expand...

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)
Strict Off, which itself has benefits & pitfalls. For me Option Strict On is
the better way to go...
Click to expand...
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
 
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.
Click to expand...
And therefore ...............
I am not with those who say you should always to use it.
Click to expand...
................always use it
But I do not agree that it is "Better"
Click to expand...
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 said:
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.
Click to expand...

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"
Click to expand...

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.
 
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.
 
Actually, the exact opposite is true, but I understand your point.
Click to expand...

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

Cor
 
Bill,
On

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?
Click to expand...

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 said:
news:umvJ%[email protected]...
Click to expand...
<<snip>>
 
No, referencing anything with a Strongly typed dataset is much faster b/c
it's typed. Just like Option Strict On vs. Off.
 
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.
Click to expand...

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
 
Back
Top