Checking for table existence

[Guru]

You should simply test for the length of Item.SomeProperty beforehand

You can't read code, can you?

nLen = PerformSomeReallyWeirdCalculation(Item.SomeProperty)

How do you predict the value of nLen from the value of
Item.SomeProperty.Length?

- it is way cheaper than using try/catch.

Booleshift. A single equality comparison consumes a minimum of two CPU
cycles. In the 200,000 object scenario given, your lazy, unthinking approach
would add at least 400,000 CPU cycles to the processing time merely for the
purposes of an off chance intercept of an invalid value in data that you
have no control over.

I really do hope you are not employed as a programmer anywhere. A Try/Catch
is logically equivalent to a single If/Then statement... If
SomethingGoesWrong Then Go There... Prove that a single Try/Catch is more
expensive than 400,000 potentially unnecessary equality comparisons.

The only situation when exceptions might come handy are recursions.

LMAO - what is so special about the act of recursion that it might be
conducive to using Try/Catch blocks? Or do you merely hope that I will
unquestioningly accept your idiotic assertions?

And if you try to answer the former question, I strongly recommend you
inspect your answer for extreme stupidity involving any of your attrocious
programming practices before posting it.

Dim sw As New Stopwatch
Dim nCount As Integer

sw.Start()
For nZ As Integer = 1 To 2000000
If nZ = -1 Then
Exit For
Else
nCount += 1
End If
Next
sw.Stop()

Console.WriteLine(sw.ElapsedMilliseconds)

sw.Reset()

sw.Start()
Try
For nz As Integer = 1 To 2000000
nCount += 1
Next
Catch ex As Exception
Stop
End Try
sw.Stop()

Console.WriteLine(sw.ElapsedMilliseconds)

sw.Reset()
sw.Start()
For nz As Integer = 1 To 2000000
nCount += 1
Next
sw.Stop()
Console.WriteLine(sw.ElapsedMilliseconds)

11
8
8

Weren't you saying something about Try/Catch being more expensive? Hmmm?

<SNICKER>

 

[Guru]

Sure, but that's an exception

This statement is false. The scenario he provided is exceedingly common.

I mean, you can't test whether the command will execute properly due to
parameters out of your control.

This statement is false.

Although you know that connection might drop, you can't know in advance.

This statement is false.

Dim WithEvents Pong as New Ping()

Pong.Send(IPAddress)

Private Sub Pong_PingCompleted(ByVal sender As Object, ByVal e As _
PingCompletedEventArgs) Handles Pong.PingCompleted

If e.Reply.Status <> IPStatus.Success Then
GiveUP()
ElseIf e.Reply.RoundtripTime > 750 Then
TryAgainLater()
End If

End Sub

You are assuming there is a valid connection which won't fail.

This statement is false.

That's why there are exceptions.

This statement is false.

BTW, now that I think

What? You? Think?

LMAO

 

[Miha Markic]

Dim WithEvents Pong as New Ping()

Pong.Send(IPAddress)

Private Sub Pong_PingCompleted(ByVal sender As Object, ByVal e As _
PingCompletedEventArgs) Handles Pong.PingCompleted

If e.Reply.Status <> IPStatus.Success Then
GiveUP()
ElseIf e.Reply.RoundtripTime > 750 Then
TryAgainLater()
End If

End Sub

So, based on the fact that ping succeeded *now* it won't fail in the next
second? minute? hour? And nor will the server? database?
You certainly extrapolated a lot of assertions from a successful ping.

 

[Stephany Young]

I'm having trouble figuring out if you're just a boofhead or you're actually
an arsehole.

If you've got something valid and constructive to say it then come out from
behind your cowardly alias and say it reasonably or just crawl back into
your wombat hidey-hole.

 

[Miha Markic]

Guru,

You are very offensive due to your ignorance.
Look at the referenced message and you'll see that try/catch block is
*inside* the loop. Now, redo your tests with try/catch block inside the loop
and you'll see the performance difference.

nLen = PerformSomeReallyWeirdCalculation(Item.SomeProperty)

How do you predict the value of nLen from the value of
Item.SomeProperty.Length?

You don't have to predict it. You check how long the Item.SomeProperty
string is and avoid throwing an exception if the nLen is higher. Is it as
simple as that.

Now, please, calm down and take a big breath before you start calling people
stupid, ignorant or idiots.

 

[Guru]

So, based on the fact that ping succeeded *now* it won't fail in the next
second<BITCHSLAP>

You certainly extrapolated a lot of assertions from a successful ping.

You got bitchslapped for extrapolating an assertion from a few lines of
code. The above is a real-world example based on historical data, viz the
network is unreliable if it is pinging at greater than 750ms and the
connection is likely to fail. You do know what empirical evidence gathering
is, don't you? And you do know the purpose of undertaking detailed testing
and research on networks prone to high traffic demand, yes? If so, then you
know just as well as I do that your previous claim that "you can't test
whether the command will execute properly..." is patently false; you can
test within a very good degree of likelihood whether or not the command will
execute properly based on past experience and empirical data.

So, are you going to keep arguing just to try and save face or are you going
to shut up and take your nasty medicine like a man?

 

[Guru]

Guru,

You are very offensive due to your ignorance.
Look at the referenced message and you'll see that try/catch block is
*inside* the loop. Now, redo your tests with try/catch block inside the
loop and you'll see the performance difference.

See end of this message...

How do you predict the value of nLen from the value of
Item.SomeProperty.Length?

You don't have to predict it. You check how long the Item.SomeProperty
string is and avoid throwing an exception if the nLen is higher. Is it as
simple as that.

Not so. Go back to the referenced message and read it, but first, learn to
read.

Now, please, calm down and take a big breath before you start calling
people stupid, ignorant or idiots.

...said the stupid, ignorant idiot.

Dim sw As New Stopwatch
Dim nCount As Integer

sw.Start()
For nZ As Integer = 1 To 2000000
If nZ = -1 Then
Exit For
Else
nCount += 1
End If
Next
sw.Stop()

Console.WriteLine(sw.ElapsedMilliseconds)

sw.Reset()
sw.Start()
Try
For nz As Integer = 1 To 2000000
nCount += 1
Next
Catch ex As Exception
Stop
End Try
sw.Stop()

Console.WriteLine(sw.ElapsedMilliseconds)

sw.Reset()
sw.Start()
For nz As Integer = 1 To 2000000
nCount += 1
Next
sw.Stop()
Console.WriteLine(sw.ElapsedMilliseconds)

sw.Reset()
sw.Start()
For nz As Integer = 1 To 2000000
Try
nCount += 1
Catch ex As Exception
Stop
End Try
Next
sw.Stop()
Console.WriteLine(sw.ElapsedMilliseconds)

12
8
8
7

BWAHAHAHAHAHAHAHAHAHAHA!

You were saying, mister genius MVP?

 

[Bill McCarthy]

The code you posted is not the equivalent. In the first block, you test the
condition on each iteration, yet for the Try Catch you set up the block only
once. The equivalent code for the Try catch would be:


sw.Start()
Try
For nz As Integer = 1 To 2000000
nCount += 1
Next
Catch ex As Exception
Stop
End Try
sw.Stop()

 

[Bill McCarthy]

You need to increase the number of iterations to get anything meaningful,
and also need to ensure you aren't seeing a JIT optimization due to the
block placement. The later can be usually solved by either calling separate
methods , or by repeating the same blocks in code. When you do this, you
will see the cost is about the same when the exception condition is not
triggered. However, if testing for the exception condition you will find
that the exception is more expensive.

 

[Guru]

The code you posted is not the equivalent.

Correct. The code I posted is not the equivalent...

In the first block, you test the condition on each iteration, yet for the
Try Catch you set up the block only once. The equivalent code for the Try
catch would be:


sw.Start()
Try
For nz As Integer = 1 To 2000000
nCount += 1
Next
Catch ex As Exception
Stop
End Try
sw.Stop()
...

The code I posted is the exact same.

BWAHAHAHAHAHAHAHAHAH! You less than useless beetlebrain.

 

[Bill McCarthy]

Correct. The code I posted is not the equivalent...


The code I posted is the exact same.

BWAHAHAHAHAHAHAHAHAH! You less than useless beetlebrain.

Your first post however did not contain the same code: you simply got it
wrong. I suppose that's why you have to resort to ad hominems.

 

[Miha Markic]

sw.Reset()
sw.Start()
For nz As Integer = 1 To 2000000
nCount += 1
Next
sw.Stop()
Console.WriteLine(sw.ElapsedMilliseconds)

sw.Reset()
sw.Start()
For nz As Integer = 1 To 2000000
Try
nCount += 1
Catch ex As Exception
Stop
End Try
Next
sw.Stop()
Console.WriteLine(sw.ElapsedMilliseconds)

12
8
8
7

BWAHAHAHAHAHAHAHAHAHAHA!

You were saying, mister genius MVP?

Based on your results, a simple loop is slower than same loop with try/catch
block? Now, that's a representative result.
Looks like try/catch block actually increases the speed, perhaps reduces the
cpu cycles required for an operation.
I suggest you to follow your recipe: placer try/catch blocks in every loop
you have and your app will run faster.

 

[Miha Markic]

"Miha Markic" <miha at rthand com> wrote in message

You got bitchslapped for extrapolating an assertion from a few lines of
code. The above is a real-world example based on historical data, viz the
network is unreliable if it is pinging at greater than 750ms and the
connection is likely to fail. You do know what empirical evidence
gathering is, don't you? And you do know the purpose of undertaking
detailed testing and research on networks prone to high traffic demand,
yes? If so, then you know just as well as I do that your previous claim
that "you can't test whether the command will execute properly..." is
patently false; you can test within a very good degree of likelihood
whether or not the command will execute properly based on past experience
and empirical data.

So, you are saying, that command against database will always succeed based
on ping test?
I suggest you to start fortune telling business. You could do a ping and
predict the future...

 

[Guru]

You need to<BITCHSLAP>

You do it.

 

[Guru]

Your first post however did not contain the same code: you simply got it
wrong<BITCHSLAP>

You got it wrong, you less than useless imbecile.

 

[Guru]

Based on your results<BITCHSLAP>

I take it you are incapable of copying the code and producing your own
results.

 

[Bill McCarthy]

You do it.

Well I suggest you take the time to look at what was said to you. The test
results you posted were ludicrous. That you would expect to see a
difference around code that only takes 7ms, is silly. If you actually
looked at your results and applied some logic, it *should* be obvious that
what you posted as results were just some aberration, not science, not
engineering, and not quality testing. If you followed the suggestions I
made, you would see how wrong you were with the assumptions you posted.

 

[Guru]

So, you are saying, that command against database will always succeed
based on ping test?

No. I am saying you can test within a very good degree of likelihood whether
or not the command will execute properly based on past experience and
empirical data.

Can't you read or something?

I suggest you to start fortune telling business. You could do a ping and
predict the future...

It must be really sad for you, being so stupid as to blindly try to get
someone far smarter than you to agree that they are claiming something that
is completely different to what they are claiming, and persistently failing.

You poor, unthinking sap.

 

[Guru]

Well I suggest you take the time to look at what was said to you. The
test results you posted were ludicrous.

Then post your own.

HTH

 

[Bill McCarthy]

You got it wrong, you less than useless imbecile.

Actually I got it right, but thanks for playing.

Your first post was wrong, in fact all the assumptions you've made on the
code you have posted have been wrong.

As to this particular issue, I suggest you learn how to follow a thread in
a news reader rather than stomp your little feet like a child and start name
calling.