Article: Achieve pure .NET development with VB.NET

[John Butler]

http://builder.com.com/article.jhtml?id=u00320021106lan01.htm

Content:
"I have worked with companies that have made a long-term commitment to using
VB.NET as their core development tool, and one of their biggest concerns is
that they're not writing Pure Framework code unless they use C#. "

Article discusses why VB is viable etc.

rgds
John Butler

[John Butler]

"John Butler" <nospamjrbutler@btinternet.com> wrote in message
news:3dc9bd64@tnews.web.devx.com...
> http://builder.com.com/article.jhtml?id=u00320021106lan01.htm

Um...article is more a quick discussion of some VB internals...but may be of
interest.

[Mike Mitchell]

On Thu, 7 Nov 2002 01:20:14 -0000, "John Butler"

>Article discusses why VB is viable etc.

I liked the part where he said: "In fact, some VB functions
(particularly conversion) offer better performance than calling native
CLR objects. For instance, CInt() is better than calling the Convert
object."

So, better performance got lost in all the oopification madness, yes?
(Plus clarity, ease-of-use, accessibility, etc etc...)

And then there's:

"Also, this library provides access to common environment constants
that VB developers have learned to use like vbCrLf. You create the
same constants by using either the System.Environment.Newline method
or System.Convert.ToChar(13) & System.Convert.ToChar(10)."

Eh? System.Convert.ToChar(13) ? Is that a foreign language, mother?
What utter nonsense to need stuff like that when we've been happy with
vbCrLf for years. Of course, I realise that the .Netizens will
interpret this as me just being a troll or negative or a f***wit, but
I'm sorry for having to keep on pointing out that the emperor ain't
wearin' anything! Not yesterday; not today; and probably not tomorrow.

By the way, nice of 'em to tell us that the VisualBasic.Compatibility
namespace may not be supported in future versions. It would also have
been nice if the VB6 carton had had wording printed on the outside (so
that we could read it before purchase) that the traditional VB inside
could be superseded in the not too distant future by an almost
completely incompatible new kind of product. They probably had the
ditches dug for the VB.Net foundations as VB6 was coming on stream.

"Use equivalent functions or objects from other .NET namespaces
instead."

In other words, don't use the intrinisc VB6 functions which offer
better performance; instead, use the CLR ones like
System.Convert.ToChar(13), which are just so darn readable!

Crikey, the author of that article really enjoys punishment, doesn't
he! He recommends that his customers avoid using the upgrade wizard at
all! So not only NO backward compatibility to speak of, but when
Microsoft actually do provide the semblance of a conversion wizard,
people are saying DON'T USE IT, GUYS! I'd say, if the conversion
wizard was better, maybe all the fuss over VB6/VB.Net would be water
under the bridge by now. But maybe the hairshirts wouldn't even wear
it then.

MM

[Tom Shelton]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:sisksus4hv1ehrbv1bv6kdqqeiavjlogk9@4ax.com...
> On Thu, 7 Nov 2002 01:20:14 -0000, "John Butler"
>
> >Article discusses why VB is viable etc.
>
> I liked the part where he said: "In fact, some VB functions
> (particularly conversion) offer better performance than calling native
> CLR objects. For instance, CInt() is better than calling the Convert
> object."
>
> So, better performance got lost in all the oopification madness, yes?
> (Plus clarity, ease-of-use, accessibility, etc etc...)

This has nothing to do with OOP, it has to do with implementation.

> And then there's:
>
> "Also, this library provides access to common environment constants
> that VB developers have learned to use like vbCrLf. You create the
> same constants by using either the System.Environment.Newline method
> or System.Convert.ToChar(13) & System.Convert.ToChar(10)."

So use vbCrLf - what's your beef.

> Eh? System.Convert.ToChar(13) ? Is that a foreign language, mother?
> What utter nonsense to need stuff like that when we've been happy with
> vbCrLf for years. Of course, I realise that the .Netizens will
> interpret this as me just being a troll or negative or a f***wit, but
> I'm sorry for having to keep on pointing out that the emperor ain't
> wearin' anything! Not yesterday; not today; and probably not tomorrow.

Your point is meaningless, since if your a VB.NET developer you don't have
to use those other methods.

> By the way, nice of 'em to tell us that the VisualBasic.Compatibility
> namespace may not be supported in future versions. It would also have
> been nice if the VB6 carton had had wording printed on the outside (so
> that we could read it before purchase) that the traditional VB inside
> could be superseded in the not too distant future by an almost
> completely incompatible new kind of product. They probably had the
> ditches dug for the VB.Net foundations as VB6 was coming on stream.

They did - a long time ago, where have you been?

> "Use equivalent functions or objects from other .NET namespaces
> instead."

Yes for things in Microsoft.VisualBasic.Compatability. That's completely
different from Microsoft.VisualBasic. There separate dll's even.

> In other words, don't use the intrinisc VB6 functions which offer
> better performance; instead, use the CLR ones like
> System.Convert.ToChar(13), which are just so darn readable!

Hey, f***wit (to use your own wording) - CInt lives in
Microsoft.VisualBasic, not Microsoft.VisualBasic.Compatability. CInt and
most other "instrinsic" VB6 functions aren't going anywhere - that was the
point of this quote at the end:

*********
Microsoft.VisualBasic is part of the implementation of the VB language
itself. The functions are true .NET and were not added solely for
compatibility with earlier versions of Visual Basic. Leaving the project
Imports statement in a VS.NET project has no impact on the performance of a
VB.NET application. Basically, it tells the compiler where to find
compatibility code if the program attempts to use it.

The .NET Framework will always have the Microsoft.VisualBasic namespace, and
it will always be in the redistribution. In the words of one of the members
of the VB.NET product team, "You're not gaining anything by removing
Microsoft.VisualBasic.dll. The functions the DLL exposes are not VB6
baggage; they are fully implemented in VB.NET, familiar to VB programmers,
and forward compatible. Lastly, if you reuse code from any VB samples, they
will use these functions. Removing the DLL does not make the application
more pure; it means you are removing helpful classes."
*****

And I dont find Convert.ToInt32(...) any less readable then CInt. Mike, you
almost never include the fully qualified name... Thats why we have the
Imports statement.

[snip - anti-conversion wizard rant]

Tom Shelton

[Jason]

"Tom Shelton" <toms@dakcs.com> wrote:
>
>"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>news:sisksus4hv1ehrbv1bv6kdqqeiavjlogk9@4ax.com...
<<SNIP>>

Tom, you are wasting your time. Mike has this same argument about four times
a week with anyone who cares to discuss it. In all the time I have been
reading his posts, he has not changed his opinion of VB.NET or of Microsoft.
The only person who is more stubborn is Bill, and I am beginning to think
they may actually be the same person. The only difference between them is
that Bill is flagrantly anti-everything, and Mike stays on subject. And
Bill is a troll, whereas I do not believe that Mike is.

Also, Mike has not started to learn VB.NET, so all the arguments he makes
are from what he reads in magazines, on the web, and from other posts. This
makes it difficult to have an intelligent argument with him, since he really
does not know what he is arguing about.

Mike isn't really interested in learning anything new about .NET. He is
just interested in justifying his position on VB6, and he believes that VB7
should accept and run VB6 code. He does not understand - well, pretty much
anything - about the new architectures that .NET supports, nor does he seem
to be interested in learning new concepts in programming. He does not want
to understand. He only wants to continue to do the things he always did
in VB6 carried forward to VB7.

In other words, Mike is a dinosaur. Little brain, big roar, facing extinction.

Good luck with the glaciers, Mike. It's gonna be a cold winter.

[John Butler]

"Jason" <jason@hotmail.com> wrote in message
news:3dcacab5$1@tnews.web.devx.com...
> In other words, Mike is a dinosaur. Little brain, big roar, facing
extinction.
>
> Good luck with the glaciers, Mike. It's gonna be a cold winter.

He he, Roflmao

:-)

rgds
John Butler

[Tom Shelton]

> And I dont find Convert.ToInt32(...) any less readable then CInt. Mike,
you
> almost never include the fully qualified name... Thats why we have the
> Imports statement.

By the way, one usefull feature of using the convert class:

Module Module1
Sub Main()
Dim i As Integer = 25
Dim binary As String

binary = Convert.ToString(i, 2)
Console.WriteLine(binary)
End Sub
End Module

' Output
25 = 11001

So much for that classic homework problem :)

Tom Shelton

[Tom Shelton]

"Tom Shelton" <tom@mtogden.com> wrote in message
news:3dcb1cd4@tnews.web.devx.com...
>
> > And I dont find Convert.ToInt32(...) any less readable then CInt. Mike,
> you
> > almost never include the fully qualified name... Thats why we have the
> > Imports statement.
>
> By the way, one usefull feature of using the convert class:
>
> Module Module1
> Sub Main()
> Dim i As Integer = 25
> Dim binary As String
>
> binary = Convert.ToString(i, 2)
> Console.WriteLine(binary)
> End Sub
> End Module
>
> ' Output
> 25 = 11001
>
> So much for that classic homework problem :)
>
> Tom Shelton

Dang it! I forgot to change the last line to:

Console.WriteLine("{0} = {1}", i, binary)

Tom Shelton

[Blob]

"Jason" <jason@hotmail.com> wrote:
>
>"Tom Shelton" <toms@dakcs.com> wrote:
>>
>>"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>>news:sisksus4hv1ehrbv1bv6kdqqeiavjlogk9@4ax.com...
><<SNIP>>
>
>Tom, you are wasting your time. Mike has this same argument about four
times
>a week with anyone who cares to discuss it. In all the time I have been
>reading his posts, he has not changed his opinion of VB.NET or of Microsoft.
> The only person who is more stubborn is Bill, and I am beginning to think
>they may actually be the same person. The only difference between them
is
>that Bill is flagrantly anti-everything, and Mike stays on subject. And
>Bill is a troll, whereas I do not believe that Mike is.
>
>Also, Mike has not started to learn VB.NET, so all the arguments he makes
>are from what he reads in magazines, on the web, and from other posts.
This
>makes it difficult to have an intelligent argument with him, since he really
>does not know what he is arguing about.
>
>Mike isn't really interested in learning anything new about .NET. He is
>just interested in justifying his position on VB6, and he believes that
VB7
>should accept and run VB6 code. He does not understand - well, pretty much
>anything - about the new architectures that .NET supports, nor does he seem
>to be interested in learning new concepts in programming. He does not want
>to understand. He only wants to continue to do the things he always did
>in VB6 carried forward to VB7.
>
>In other words, Mike is a dinosaur. Little brain, big roar, facing extinction.
>
>Good luck with the glaciers, Mike. It's gonna be a cold winter.

Jason,

I just looked up lemming and the dictionary and found your picture. Do you
have any thoughts of your own? You should get out more and realize .NET
is not life.

[Jason]

"Blob" <blob@blobbloblboblo.com> wrote:
>I just looked up lemming and the dictionary and found your picture. Do
you
>have any thoughts of your own? You should get out more and realize .NET
>is not life.

I just looked up "troll" in the dictionary and found a picture of an inflamed
rectum ... no, wait, that's a picture of you. But you can see how I could
get confused.

[Blob]

"Jason" <jason@hotmail.com> wrote:
>
>"Blob" <blob@blobbloblboblo.com> wrote:
>>I just looked up lemming and the dictionary and found your picture. Do
>you
>>have any thoughts of your own? You should get out more and realize .NET
>>is not life.
>
>I just looked up "troll" in the dictionary and found a picture of an inflamed
>rectum ... no, wait, that's a picture of you. But you can see how I could
>get confused.
>


Holy crap, that's funny. So, did you think that up on your own? Still no
comment from the peanut gallery on the speed issues we were talking about
over in the C# group? Surely you remember "speed is a weak reason to choose
a piece of code"? Not exactly those words but that's what it ammounted to.

[Jason]

"Blob" <blob@blobbloblboblo.com> wrote:
>>Holy crap, that's funny. So, did you think that up on your own?

Naw. Spent all night looking up variations of "insults" and "lemming" on
Google.


>Still no
>comment from the peanut gallery on the speed issues we were talking about
>over in the C# group? Surely you remember "speed is a weak reason to choose
>a piece of code"? Not exactly those words but that's what it ammounted
to.

I think maybe you are referring to another "Jason." I responded once to
your IL thread on the "C# Technical" board, only just to comment that you
were arguing a case for speed on some code that would get run once each time
you start the program, or something like that. I did say that a couple of
extra IL instructions, run once, would not make a noticable difference in
the running time of the program. I don't recall if you replied or not.

As for my opinion of .NET speed, I have not found it to be lacking at all.
I have not done a scientific head-to-head comparison with VB, but I'm not
doing anything that requires a great amount of CPU. Mostly drawing GUIs
and some network operations. So as far as I can tell, the VB code and the
.NET code run neck and neck. Mind you, I am running 2GHz P4 machines, so
there may be a larger difference at, say, 300MHz.

Anyway, my design philosophy is generally to pick decent algorithms, make
the code as clear as possible, and only worry about profiling if I notice
an actual problem. I am most concerned with robust, maintainable, well documented
code. I find that usually, if you design the algorithms correctly in the
first place, a few extra IL statements won't hurt you enough to bother with
them.

In fact, I am using COM Interop quite a bit. If I were really concerned
with speed above all else, I would just stick with VB6. COM Interop is a
pretty heavy-handed protocol - it slows things down measurably. But that
doesn't mean it slows them down enough to make a real difference, and like
I said before, I am more concerned with robust, maintainable, well documented
code. For me, fast enough is just right. So I don't spend a whole lot of
time twiddling IL bits.

[Jason Sobell \(iGadget\)]

> I think maybe you are referring to another "Jason."

Wasn't me :)

Cheers,
Jason S

[blob]

>Naw. Spent all night looking up variations of "insults" and "lemming" on
>Google.
You need to get a life.

>I think maybe you are referring to another "Jason." I responded once to
>your IL thread on the "C# Technical" board, only just to comment that you
>were arguing a case for speed on some code that would get run once each
time
>you start the program, or something like that.
I believe it went something like:

>If it takes 100 microseconds to run the fast one, and 133 microseconds to
>run the slow one (you didn't mention actual running times, so this is a
>guess),
>haven't you spent an inordinate amount of time fretting over a code >optimization
>that no one will ever notice?

Having said that you are "only" doing gui stuff, I would have expected this.
I don't do gui. All of my code is middle tier business logic that is hit
continuously and needs to be as fast as it can. And believe me people do
notice.


>Not saying that it is a bad thing to use your solution over Jay's, but the
>arguments for preferring one over the other seem really weak.
Speed is a weak argument? Take that 100 ms and multiply that by 100000 users
running 10 transactions per second and compare it to 133 ms. Hmmm big difference.



I did say that a couple of
>extra IL instructions, run once, would not make a noticable difference in
>the running time of the program. I don't recall if you replied or not.

No you didn't but I will oblige. Depending on the types of instructions
there may be a big difference. Reference CLI.doc


>As for my opinion of .NET speed, I have not found it to be lacking at all.
> I have not done a scientific head-to-head comparison with VB, but I'm not
>doing anything that requires a great amount of CPU. Mostly drawing GUIs
>and some network operations.
Well that explains everything.

>Anyway, my design philosophy is generally to pick decent algorithms, make
>the code as clear as possible, and only worry about profiling if I notice
>an actual problem. I am most concerned with robust, maintainable, well
documented
>code. I find that usually, if you design the algorithms correctly in the
>first place, a few extra IL statements won't hurt you enough to bother with
>them.
Hmmm. Are you sure about that?


>
>In fact, I am using COM Interop quite a bit. If I were really concerned
>with speed above all else, I would just stick with VB6.
Please don't use those two in the same sentence. VB6 and speed just don't
go together. If you wanted speed you would use C++.


I'll stop there. The rest also made no sense.

[blob]

"Jason Sobell \(iGadget\)" <iGadget_@hotmail.com> wrote:
>> I think maybe you are referring to another "Jason."
>
>Wasn't me :)
>
>Cheers,
> Jason S
>
>

Is it coincidence that you're both named Jason? Or are you the same person,
one dumber than the other?

[Kunle Odutola]

blob wrote:

>> Not saying that it is a bad thing to use your solution over Jay's,
>> but the arguments for preferring one over the other seem really weak.

> Speed is a weak argument? Take that 100 ms and multiply that by
> 100000 users running 10 transactions per second and compare it to 133
> ms. Hmmm big difference.

Even when you factor in the cost of network roundtrips?. Didn't think so.

Kunle

[blob]

"John Butler" <nospamjrbutler@btinternet.com> wrote:
>
>"blob" <blob@bloblblblbbl.com> wrote in message
>news:3dcff3bd$1@tnews.web.devx.com...
>
>Your policy being what it is, namely to insult 100% of the people that post
>on this forum....any potential messages of wisdom you might have, are being
>lost, as you are consigned to people's killfiles. Pity really, because
>sometimes you make the odd bit of sense, in between telling anyone you
>happen to be talking to, to f£"* off etc etc.
>
>We all get a bit worked up every now and then...you seem to be a permanently
>angry person....lighten up will ya!
>
>rgds
>John Butler
>


And I'll say it again, it's a joke. whoop de freakin do

[John Butler]

"blob" <blob@bloblblblbbl.com> wrote in message
news:3dcff3bd$1@tnews.web.devx.com...

Your policy being what it is, namely to insult 100% of the people that post
on this forum....any potential messages of wisdom you might have, are being
lost, as you are consigned to people's killfiles. Pity really, because
sometimes you make the odd bit of sense, in between telling anyone you
happen to be talking to, to f£"* off etc etc.

We all get a bit worked up every now and then...you seem to be a permanently
angry person....lighten up will ya!

rgds
John Butler

[Blob]

"Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
>blob wrote:
>
>>> Not saying that it is a bad thing to use your solution over Jay's,
>>> but the arguments for preferring one over the other seem really weak.
>
>> Speed is a weak argument? Take that 100 ms and multiply that by
>> 100000 users running 10 transactions per second and compare it to 133
>> ms. Hmmm big difference.
>
>Even when you factor in the cost of network roundtrips?. Didn't think so.
>
>Kunle
>

Do you really understand what you were trying to say there? Didn't think
so.

I don't know Kunle but if your code is slow and you tack on round trips the
problem is compounded. The code in the sample (if you knew what you were
talking about ) was about doing security checks which of course go over the
network and in my case to a mainframe. Now please leave me alone. I've been
told I'm a jerk so I'm trying to lay off idiots for awhile.

[Jason Sobell \(iGadget\)]

"Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote in
message news:3dd03195@tnews.web.devx.com...
> blob wrote:
>
> >> Not saying that it is a bad thing to use your solution over Jay's,
> >> but the arguments for preferring one over the other seem really weak.
>
> > Speed is a weak argument? Take that 100 ms and multiply that by
> > 100000 users running 10 transactions per second and compare it to 133
> > ms. Hmmm big difference.
>
> Even when you factor in the cost of network roundtrips?. Didn't think so.

Rather a pointless comment, because the overhead is constant, so 33ms extra
delay remains. The last person in the chain may be waiting 3mins longer for
their data, although only if your sever (or network traffic) was running
100% load.
Relatively speaking, it may make 25% or 2% difference, but an accumulation
of small inefficiencies can result in something very undesirable :)
Not all methods at the business layer run once per network transaction. An
operation may be applied to 1000 database records and return one value, in
which case the 25% could be reflected as perhaps a 22% increase in response
time.

Best thing to do is not argue these points. Blob is obnoxious, but he's
correct in what he's saying. Those of us who do a lot of GUI stuff can
ignore the 33ms delay on a screen that the user spends 60secs filling in.
Those of us who code business logic and algorithms find these inefficiences
have massive impact on the performance of our apps.

Just some thoughts.

Cheers,
Jason

p.s. Blob, No we are not the same person (as far as I know), and while I am
certainly the dumber of the two of us, I am the only genuine Jason ( and I
have the receipt to prove it)

[Blob]

"Jason Sobell \(iGadget\)" <iGadget_@hotmail.com> wrote:
>
>"Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote in
>message news:3dd03195@tnews.web.devx.com...
>> blob wrote:
>>
>> >> Not saying that it is a bad thing to use your solution over Jay's,
>> >> but the arguments for preferring one over the other seem really weak.
>>
>> > Speed is a weak argument? Take that 100 ms and multiply that by
>> > 100000 users running 10 transactions per second and compare it to 133
>> > ms. Hmmm big difference.
>>
>> Even when you factor in the cost of network roundtrips?. Didn't think
so.
>
>Rather a pointless comment, because the overhead is constant, so 33ms extra
>delay remains.
Actually this is not the case. This overhead is never constant in the case
I was referring to. When I am attempting to authenticate a user(much less
authorize him) the time increases from 33 to, I don't know, say 100. Depending
on the "speed" of the validation code and how well I architect it, the time
can be minimized using any number of techniques. My code is hit 100% harder
between 5 and 6 pm depending on the time zone. And as you can figure there
is a time when my components are hit extremely hard due to all time zones
overlapping and had to be written to perform from 1 - 100000 concurrent users
executing 3 transactions (distributed for Kunle) per minute. You can figure
how many transactions per second had to be supported. This include sign-on,
authentication, validation, authorization and then the initial retrieval
of data from an Oracle database. Not bad with the amount of hardware we
currently have configured.

>The last person in the chain may be waiting 3mins longer for
>their data, although only if your sever (or network traffic) was running
>100% load.
If not architected correctly and I have seen this many, many times.

>Relatively speaking, it may make 25% or 2% difference, but an accumulation
>of small inefficiencies can result in something very undesirable :)
Agreed.

>Best thing to do is not argue these points. Blob is obnoxious, but he's
>correct in what he's saying. Those of us who do a lot of GUI stuff can
>ignore the 33ms delay on a screen that the user spends 60secs filling in.
>Those of us who code business logic and algorithms find these inefficiences
>have massive impact on the performance of our apps.
Why thank you, a**hole. That's just supposed to be funny, don't take it
so seriously.

You see, I can carry a conversation when I am not on the defensive.


>p.s. Blob, No we are not the same person (as far as I know), and while I
am
>certainly the dumber of the two of us,

I wouldn't agree with that statement either.

[Jason]

"Jason Sobell \(iGadget\)" <iGadget_@hotmail.com> wrote:
>Best thing to do is not argue these points. Blob is obnoxious, but he's
>correct in what he's saying. Those of us who do a lot of GUI stuff can
>ignore the 33ms delay on a screen that the user spends 60secs filling in.
>Those of us who code business logic and algorithms find these inefficiences
>have massive impact on the performance of our apps.
>
>Just some thoughts.

You are correct in that server-side inefficiencies can add up faster than
client side inefficiencies. However, the problem is being overstated. Take
a look at J2EE and get back to me. If Sun can sell that as an "enterprise"
application server, you can get away with pretty much anything you want in
.NET and still be faster.

And I assure you, there is more than one Jason posting to this board. That
is, if you are actually named Jason too...

[Kunle Odutola]

Blob wrote:
> "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk>
> wrote:
>> blob wrote:
>>
>>>> Not saying that it is a bad thing to use your solution over Jay's,
>>>> but the arguments for preferring one over the other seem really
>>>> weak.
>>
>>> Speed is a weak argument? Take that 100 ms and multiply that by
>>> 100000 users running 10 transactions per second and compare it to
>>> 133 ms. Hmmm big difference.
>>
>> Even when you factor in the cost of network roundtrips?. Didn't
>> think so.
>>
>> Kunle
>>
>
> Do you really understand what you were trying to say there?

Yes.

> Didn't think so.

Why?

> I don't know Kunle but if your code is slow and you tack on round
> trips the problem is compounded. The code in the sample (if you knew
> what you were talking about ) was about doing security checks which
> of course go over the network and in my case to a mainframe.

GetUserName() wasn't it?. No matter, if the network roundtrip cost is
1000ms, worrying about 33ms is a bit silly. It is nice to not have it but
it's not that big a deal compared to the1000ms. Of course the roundtrip
might be 3300ms....

Kunle

[Kunle Odutola]

Jason Sobell (iGadget) wrote:

>>> Speed is a weak argument? Take that 100 ms and multiply that by
>>> 100000 users running 10 transactions per second and compare it to
>>> 133 ms. Hmmm big difference.
>>
>> Even when you factor in the cost of network roundtrips?. Didn't
>> think so.
>
> Rather a pointless comment, because the overhead is constant, so 33ms
> extra delay remains.

It's about putting performance into it's proper context. If the roundtrip
cost is 1000ms, saving 33ms would be of little benefit to the users. Getting
faster network hardware might be more sensible (and cheaper).

> Best thing to do is not argue these points. Blob is obnoxious, but
> he's correct in what he's saying. Those of us who do a lot of GUI
> stuff can ignore the 33ms delay on a screen that the user spends
> 60secs filling in.

Depends on what the code is doing. If it is called 8 times per sec, it might
be disastrous.

> Those of us who code business logic and algorithms
> find these inefficiences have massive impact on the performance of
> our apps.

I disagree. They might. And they might not. It depends on many more factors
than "it's a server-side component/app".

Kunle

[Jason Sobell \(iGadget\)]

"Blob" <blob@blobbloblboblo.com> wrote in message
news:3dd06262$1@tnews.web.devx.com...
>
> "Jason Sobell \(iGadget\)" <iGadget_@hotmail.com> wrote:
> >
> >"Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote in
> >message news:3dd03195@tnews.web.devx.com...
> >> blob wrote:
> >>
> >> >> Not saying that it is a bad thing to use your solution over Jay's,
> >> >> but the arguments for preferring one over the other seem really
weak.
> >>
> >> > Speed is a weak argument? Take that 100 ms and multiply that by
> >> > 100000 users running 10 transactions per second and compare it to 133
> >> > ms. Hmmm big difference.
> >>
> >> Even when you factor in the cost of network roundtrips?. Didn't think
> so.
> >
> >Rather a pointless comment, because the overhead is constant, so 33ms
extra
> >delay remains.
> Actually this is not the case. This overhead is never constant in the
case
> I was referring to. When I am attempting to authenticate a user(much less
> authorize him) the time increases from 33 to, I don't know, say 100.
Depending
> on the "speed" of the validation code and how well I architect it, the
time
> can be minimized using any number of techniques. My code is hit 100%
harder
> between 5 and 6 pm depending on the time zone. And as you can figure
there
> is a time when my components are hit extremely hard due to all time zones
> overlapping and had to be written to perform from 1 - 100000 concurrent
users
> executing 3 transactions (distributed for Kunle) per minute. You can
figure
> how many transactions per second had to be supported. This include
sign-on,
> authentication, validation, authorization and then the initial retrieval
> of data from an Oracle database. Not bad with the amount of hardware we
> currently have configured.

Doh, I wasn't responding to your message you dope :)
I was pointing out that saying "a delay that small doesn't matter" was
pointless and incorrect.
i.e. I was agreeing with you.
You've now written about 20 lines of code agreeing with me.

> >The last person in the chain may be waiting 3mins longer for
> >their data, although only if your sever (or network traffic) was running
> >100% load.
> If not architected correctly and I have seen this many, many times.

Me too. Hence why I agreed.

> >Relatively speaking, it may make 25% or 2% difference, but an
accumulation
> >of small inefficiencies can result in something very undesirable :)
> Agreed.

Again?

> >Best thing to do is not argue these points. Blob is obnoxious, but he's
> >correct in what he's saying. Those of us who do a lot of GUI stuff can
> >ignore the 33ms delay on a screen that the user spends 60secs filling in.
> >Those of us who code business logic and algorithms find these
inefficiences
> >have massive impact on the performance of our apps.
> Why thank you, a**hole. That's just supposed to be funny, don't take it
> so seriously.
>
> You see, I can carry a conversation when I am not on the defensive.
>
>
> >p.s. Blob, No we are not the same person (as far as I know), and while I
> am
> >certainly the dumber of the two of us,
>
> I wouldn't agree with that statement either.
Well shucks, is that a compliment for me or an insult for Jason v2?

[blob]

"Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
>Blob wrote:
>> "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk>
>> wrote:
>>> blob wrote:
>>>
>>>>> Not saying that it is a bad thing to use your solution over Jay's,
>>>>> but the arguments for preferring one over the other seem really
>>>>> weak.
>>>
>>>> Speed is a weak argument? Take that 100 ms and multiply that by
>>>> 100000 users running 10 transactions per second and compare it to
>>>> 133 ms. Hmmm big difference.
>>>
>>> Even when you factor in the cost of network roundtrips?. Didn't
>>> think so.
>>>
>>> Kunle
>>>
>>
>> Do you really understand what you were trying to say there?
>
>Yes.
>
>> Didn't think so.
>
>Why?
>
>> I don't know Kunle but if your code is slow and you tack on round
>> trips the problem is compounded. The code in the sample (if you knew
>> what you were talking about ) was about doing security checks which
>> of course go over the network and in my case to a mainframe.
>
>GetUserName() wasn't it?. No matter, if the network roundtrip cost is
>1000ms, worrying about 33ms is a bit silly. It is nice to not have it but
>it's not that big a deal compared to the1000ms. Of course the roundtrip
>might be 3300ms....
>
>Kunle
>

OK, I hate to say this but we are in agreement. Unfortunately when I benchmark
network roundtrips are included. Why wouldn't they be? You can take measurements
of your local components but if not combined with all possible scenarios,
your benchmarks are swayed a little(well maybe a lot).

Jason, if you are reading this, it just goes to show people read what I post
even on other groups, even though they may not admit it.

[blob]

>Well shucks, is that a compliment for me or an insult for Jason v2?

I never compliment anyone, except the wife and she has to be exceptional
to get that. I mean really exceptional.