Asp Forum - canada goose toronto retailer Gwafyxc - microsoft.public.inetserver.asp.general

pvgzetoq

12/28/2013 4:09:00 PM

<a href=http://www.viniplanete.fr/2013/12/06/canada-goose-parka-norway/... goose parka norway</a> The Provillus Topical Cream for Males is developed with 5% Minoxidil. The "open hand" and "mutual respect" Obama offered Tehran in 2009 have yielded nothing. <a href=http://www.nilzaboden.se/canada-goose-lodge-down-vest-c-17_27/... Goose Lodge Down Vest</a> Ajjxuh <a href=http://www.canadagoosparis.fr/canada-goose-palliser-coat-c-39_48/doudoune-canada-goose-palliser-baie-pas-cher-onlinee-p-161.html&g... Canada Goose Palliser Baie pas cher onlinee</a>
<a href=http://www.anartisteprod.fr/2013/12/canada-goose-le-prix/... goose le prix</a> Yaimoj In addition, you should spend from $150.00 to $500.00 on an authentic Gucci wallet. <a href=http://www.ateliermosaiquetess.fr/canada-goose-thompson-jacket-c-39_49/vente-canada-goose-thompson-femme-baie-en-ligne-paris-p-162.htm... Canada Goose Thompson Femme Baie En Ligne Paris</a>
<a href=http://www.bengansror.se/officiella-parajumpers-big-bend-m-jacka-svart-man-webbutik>... Parajumpers Big Bend-M jacka svart m?n webbutik</a> 9292435772

3 Answers

Cowboy

12/3/2007 3:26:00 PM

Performance is one metric in development, not the only metric.

Let's take the DataReader. You end up with a couple of choices.

1. You keep the connection open until you use the reader (expensive)
2. You pack the reader into objects or something else

I would shy away from #1, as it will ultimately kill you. If you do #2, you
lose performance. The question is: Whose algorithm is faster, yours or
Microsoft's? Can you pack objects quicker than a DataSet? If so, you may
have more performant code, but you do so at the cost of a loss of
maintainability. Is it worth it? It depends on the application.

In general, I find maintainability costs companies far more than
performance. If I err, I will generally err on the side of maintainability.
Now, there are times you need to focus on performanc up front, but I find it
more common that you can find out if the application is below the bar using
testing tools. If so, you are fine and there is no need to squeeze out a
cycle or two. If not, you focus on the inner loop or other bits that are
called over and over again in "normal" application use.

When you look at it, performance can be the enemy of scalability,
maintainability and even security. Are you willing to throw all of these
away for a few cycles? Possibly on some applications, but, in general, the
answer is no.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:ep6GOrhMIHA.484@TK2MSFTNGP06.phx.gbl...
> Thanks, but doesn't this kind of confirm some of my concerns? How many
> times more efficient is a DataReader over a DataSet? Yes, if I want
> well-constructed code, I'm better off using the less efficient method? Or
> am I the only one concerned about performance these days?
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softci...
>
> "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
> message news:%23vam47eMIHA.4712@TK2MSFTNGP04.phx.gbl...
>> If you want a static routine, as you have written, pass back out some
>> construct. The easiest, code wise, is to pass back a DataSet. Do not pass
>> out the reader, even if you keep the connection open, as there are just
>> too many issues there.
>>
>> Here is a basic pattern you can use:
>>
>> public static DataSet ExecuteProcedure(string procName)
>> {
>> //Consider strong typing here
>> DataSet ds = new DataSet();
>>
>> using (SqlCommand cmd = new SqlCommand(procName, conn))
>> {
>> cmd.CommandType = CommandType.StoredProcedure;
>>
>> SqlDataAdapter da = new SqlDataAdapter();
>>
>> //As late as possible
>> cmd.Connection.Open();
>>
>> da.Fill(ds);
>>
>> }
>>
>> return ds;
>> }
>>
>> --
>> Gregory A. Beamer
>> MVP, MCP: +I, SE, SD, DBA
>>
>> *************************************************
>> | Think outside the box! |
>> *************************************************
>> "Jonathan Wood" <jwood@softcircuits.com> wrote in message
>> news:O1Ow$gWMIHA.4136@TK2MSFTNGP03.phx.gbl...
>>> I'm still trying to get a handle on ASP.NET and ADO.NET.
>>>
>>> Since there is a bit of code involved in executing a procedure, I
>>> thought I'd stick it in it's own routine.
>>>
>>> So I tried the following. I was able to determine this does not work
>>> because, apparently, the reader requires that the connection remains
>>> open while the reader is being used.
>>>
>>> public static SqlDataReader ExecuteProcedure(string procName)
>>> {
>>> string connStr =
>>> ConfigurationManager.ConnectionStrings["ASPNETDB"].ToString();
>>> using (SqlConnection conn = new SqlConnection(connStr))
>>> {
>>> using (SqlCommand cmd = new SqlCommand(procName, conn))
>>> {
>>> cmd.CommandType = CommandType.StoredProcedure;
>>> cmd.Connection.Open();
>>> SqlDataReader reader = cmd.ExecuteReader();
>>> return reader;
>>> }
>>> }
>>> return null;
>>> }
>>>
>>> So then how would you avoid having to rewrite this code everytime you
>>> want to execute a stored procedure?
>>>
>>> I'm also troubled by the fact that ASP.NET does not have deterministic
>>> finalization in the destructors. That means I can get into trouble if I
>>> don't use using statements. That seems to make it all the harder to do
>>> what I want to do in a clear and reliable way, and with less typing.
>>>
>>> Thanks for any tips.
>>>
>>> --
>>> Jonathan Wood
>>> SoftCircuits Programming
>>> http://www.softci...
>>>
>>
>>
>

Jonathan Wood

12/3/2007 9:09:00 PM

Cowboy,

> Let's take the DataReader. You end up with a couple of choices.
>
> 1. You keep the connection open until you use the reader (expensive)
> 2. You pack the reader into objects or something else
>
> I would shy away from #1, as it will ultimately kill you. If you do #2,
> you lose performance. The question is: Whose algorithm is faster, yours or
> Microsoft's? Can you pack objects quicker than a DataSet? If so, you may
> have more performant code, but you do so at the cost of a loss of
> maintainability. Is it worth it? It depends on the application.

Your point is well taken and I'm incorporating that into my thinking. Note
that it's not that my algorithm is quicker than Microsoft's. Rather, my
algorithm might not need all the functionality that Microsoft's more generic
DataSet algorithm might employ. But, again, that's another dimension for me
to consider.

> In general, I find maintainability costs companies far more than
> performance. If I err, I will generally err on the side of
> maintainability. Now, there are times you need to focus on performanc up
> front, but I find it more common that you can find out if the application
> is below the bar using testing tools. If so, you are fine and there is no
> need to squeeze out a cycle or two. If not, you focus on the inner loop or
> other bits that are called over and over again in "normal" application
> use.

Well, before I used C++, I used C. And before that, I used assembler.
Obviously, we all have different levels at where we are comfortable
developing software. But, here, I think things are a little different
because a successful site has the potential to slow down due to heavy usage.
So, for a Website, I think performance might just be more important than
ever before even when it doesn't seem to matter while under development.
YMMV.

> When you look at it, performance can be the enemy of scalability,
> maintainability and even security. Are you willing to throw all of these
> away for a few cycles? Possibly on some applications, but, in general, the
> answer is no.

I'm not interested in losing any of those. Hopefully, if I can understand
the technology well enough, I won't have to.

--
Jonathan Wood
SoftCircuits Programming
http://www.softci...

Cor Ligthert [MVP]

12/4/2007 6:11:00 AM

George (and not Jonathan),

I think that we agree that if you don't understand the principle of the
througput through the smallest part of a pipe, then optimalizing your
product is very hard to understand.

The smallest througput part with developing is always changing.

In past it was the processing area, however that was very quick changed to
the area to save and get the data (I am express not writting about punch
card, hard disk etc). Then it became the network when we more and more were
sharing our work.

This is still going on all the time. I think that it is at the moment again
the data saving/retrieving area that is the bottleneck while for some kind
of solutions the screen. (By instance the by you called datareader, however
for sure not the internal part of that, but the way it is retrieving the
data from its source. But that is a part that a single person can not
influence anymore, there are so many possiblilities that can influence that,
that there should be a common way to let that going, not based on the most
optimized for one situation at one time by one user).

Let us therefore stop talking about how to optimize the processing of the
internal memory.

This not meant for the areas where .Net probably never will be the solution
(The processing of a watch by instance).

Just one of my idea's

Cor

"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> schreef in
bericht news:%23ZJjFDcNIHA.484@TK2MSFTNGP06.phx.gbl...
> Performance is one metric in development, not the only metric.
>
> Let's take the DataReader. You end up with a couple of choices.
>
> 1. You keep the connection open until you use the reader (expensive)
> 2. You pack the reader into objects or something else
>
> I would shy away from #1, as it will ultimately kill you. If you do #2,
> you lose performance. The question is: Whose algorithm is faster, yours or
> Microsoft's? Can you pack objects quicker than a DataSet? If so, you may
> have more performant code, but you do so at the cost of a loss of
> maintainability. Is it worth it? It depends on the application.
>
> In general, I find maintainability costs companies far more than
> performance. If I err, I will generally err on the side of
> maintainability. Now, there are times you need to focus on performanc up
> front, but I find it more common that you can find out if the application
> is below the bar using testing tools. If so, you are fine and there is no
> need to squeeze out a cycle or two. If not, you focus on the inner loop or
> other bits that are called over and over again in "normal" application
> use.
>
> When you look at it, performance can be the enemy of scalability,
> maintainability and even security. Are you willing to throw all of these
> away for a few cycles? Possibly on some applications, but, in general, the
> answer is no.
>
> --
> Gregory A. Beamer
> MVP, MCP: +I, SE, SD, DBA
>
> *************************************************
> | Think outside the box! |
> *************************************************
> "Jonathan Wood" <jwood@softcircuits.com> wrote in message
> news:ep6GOrhMIHA.484@TK2MSFTNGP06.phx.gbl...
>> Thanks, but doesn't this kind of confirm some of my concerns? How many
>> times more efficient is a DataReader over a DataSet? Yes, if I want
>> well-constructed code, I'm better off using the less efficient method? Or
>> am I the only one concerned about performance these days?
>>
>> --
>> Jonathan Wood
>> SoftCircuits Programming
>> http://www.softci...
>>
>> "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
>> message news:%23vam47eMIHA.4712@TK2MSFTNGP04.phx.gbl...
>>> If you want a static routine, as you have written, pass back out some
>>> construct. The easiest, code wise, is to pass back a DataSet. Do not
>>> pass out the reader, even if you keep the connection open, as there are
>>> just too many issues there.
>>>
>>> Here is a basic pattern you can use:
>>>
>>> public static DataSet ExecuteProcedure(string procName)
>>> {
>>> //Consider strong typing here
>>> DataSet ds = new DataSet();
>>>
>>> using (SqlCommand cmd = new SqlCommand(procName, conn))
>>> {
>>> cmd.CommandType = CommandType.StoredProcedure;
>>>
>>> SqlDataAdapter da = new SqlDataAdapter();
>>>
>>> //As late as possible
>>> cmd.Connection.Open();
>>>
>>> da.Fill(ds);
>>>
>>> }
>>>
>>> return ds;
>>> }
>>>
>>> --
>>> Gregory A. Beamer
>>> MVP, MCP: +I, SE, SD, DBA
>>>
>>> *************************************************
>>> | Think outside the box! |
>>> *************************************************
>>> "Jonathan Wood" <jwood@softcircuits.com> wrote in message
>>> news:O1Ow$gWMIHA.4136@TK2MSFTNGP03.phx.gbl...
>>>> I'm still trying to get a handle on ASP.NET and ADO.NET.
>>>>
>>>> Since there is a bit of code involved in executing a procedure, I
>>>> thought I'd stick it in it's own routine.
>>>>
>>>> So I tried the following. I was able to determine this does not work
>>>> because, apparently, the reader requires that the connection remains
>>>> open while the reader is being used.
>>>>
>>>> public static SqlDataReader ExecuteProcedure(string procName)
>>>> {
>>>> string connStr =
>>>> ConfigurationManager.ConnectionStrings["ASPNETDB"].ToString();
>>>> using (SqlConnection conn = new SqlConnection(connStr))
>>>> {
>>>> using (SqlCommand cmd = new SqlCommand(procName, conn))
>>>> {
>>>> cmd.CommandType = CommandType.StoredProcedure;
>>>> cmd.Connection.Open();
>>>> SqlDataReader reader = cmd.ExecuteReader();
>>>> return reader;
>>>> }
>>>> }
>>>> return null;
>>>> }
>>>>
>>>> So then how would you avoid having to rewrite this code everytime you
>>>> want to execute a stored procedure?
>>>>
>>>> I'm also troubled by the fact that ASP.NET does not have deterministic
>>>> finalization in the destructors. That means I can get into trouble if I
>>>> don't use using statements. That seems to make it all the harder to do
>>>> what I want to do in a clear and reliable way, and with less typing.
>>>>
>>>> Thanks for any tips.
>>>>
>>>> --
>>>> Jonathan Wood
>>>> SoftCircuits Programming
>>>> http://www.softci...
>>>>
>>>
>>>
>>
>
>

microsoft.public.inetserver.asp.general

canada goose toronto retailer Gwafyxc

pvgzetoq

Cowboy

Jonathan Wood

Cor Ligthert [MVP]

x Login to ForumsZone