VS.NET is 10 times slower than VB6

[John Rivers]

Hello everybody,

I just wondered if anybody else has noticed this?

It takes around 6 seconds to start debugging a very simple ASPX page
with VS.NET whereas VB6 takes under 0.5 seconds, even with
very large and complex projects.

This is a real shame

John Rivers

 

[Juan T. Llibre]

John :

I can count to 3 real fast.
To count to 100 takes a little longer.

Bottom line : debugging speed isn't everything.

btw, how did you debug an ASPX file with VB6 ?

;-)



Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

 

[Eliyahu Goldin]

John,

Are you saying that you are developing web applications with VB6?

Eliyahu

 

[Mark Rae]

btw, how did you debug an ASPX file with VB6 ?

Wow - we're in the presence of genius... ;-)

 

[jasonkester]

Before ASP.NET, it was standard practice to put your business logic,
data layer, and what we currently call CodeBehind into a VB .dll and
call it via COM. It would give you an order of magnitude performance
improvement as well as letting you develop in a real IDE. You could
fire up your project in debug mode by hitting F5, just like you can
today.

So yeah, he's saying he has developed web applications with VB6. If
you were in the industry more than 3 years ago, you probaby would have
too.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[John Rivers]

you guys sure can confuse a poor little troll

i have timed it as 6 seconds between pressing F5 and the page actually
running

at $50 per hour 6 seconds is about 8 cents

that is real money!

it is just not acceptable performance - somebody agree with me!

 

[jasonkester]

How complicated are the applications you are comparing? I think you'll
find that 6 seconds remains pretty much constant as you scale up your
project. It's just the overhead involved in restarting IIS.

The last large VB/ASP project I worked on would take about 10 seconds
to fire up the debugger. I have an ASP.NET project of similar
magnitude for another client that takes about the same amount of time.


For tiny "Hello World" projects, I'd agree that VB/ASP is probably
faster. But in real world situations I've never noticed a difference.
As to whether it's acceptable to wait 6 seconds to debug? I'll have to
defer comment on that, since I can still recall a time where I'd queue
up a batch job when I left at night and hope it was finished by the
time I got to the office in the morning!

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[John Rivers]

I have two VB6 groups which are 9mb and 12mb of source code
I press F5 and I get a running app in under 1 second.
Close debugging takes 1 second.
I can compile a whole group in about 35 seconds.

With VS.NET i'm looking at 6 seconds plus to start the app
and about 4 seconds to close it again (that is hello world)

I bought a new computer with 1Gb ram just to run it and its still super
slow.

Its as bad as the java compilers.

 

[Juan T. Llibre]

re:

it is just not acceptable performance - somebody agree with me!

You're not talking about performance. You're talking about debugging.
"Debugging" and "performance throughput" are two different animals.

A 6 second debug response seems quite fast to me, considering that you're
dealing with much more complex code than VB6 ever had to deal with.

Get over it. VB6 for web apps is dead
because it's not as efficient as VB.NET.

For desktop apps you might have a point, but for web apps
VB.NET gets at least 200% more throughput than VB6 ever got.

Who cares if VB.NET debugging takes 6 seconds to start up!
All I care about is that my web *clients* get more throughput.

re:

at $50 per hour 6 seconds is about 8 cents

If you're asking these questions
and you're getting $50 an hour...you're overpaid.



Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

 

[Mark Rae]

If you're asking these questions
and you're getting $50 an hour...you're overpaid.

ROTFLMAO!

 

[John Rivers]

interesting logic
i should be paid less if i question
the bad performance of vs.net ide?

so if you pick up your new car
and it does 0-60mph in 45 seconds
whilst red lining at 7000rpm
you wouldn't question that?

in my experience if a computer is
at 100% cpu for 6 seconds just to
output "hello world" to a browser
something is very wrong indeed

i wouldn't be confident to use
such a system if my living depended on it
would you?

especially when you have a vb6 based system
that has run quickly and bug free for 3 years
why would you switch to such a system?

as most experienced developers will agree
there is more value in easy to maintain
code (and that includes a good ide) than
raw performance

especially when the bottleneck in most
applications isn't the runtime - it is
usually something else

 

[Juan T. Llibre]

re:

in my experience if a computer is at 100% cpu for 6 seconds just to
output "hello world" to a browser something is very wrong indeed

So, now you weren't "debugging" ? You were outputting "hello world" ?

Your original post stated that :

It takes around 6 seconds to start debugging a very simple ASPX page
with VS.NET whereas VB6 takes under 0.5 seconds, even with
very large and complex projects.

Which one was it ?
Were you "debugging" or were you outputting "hello world" ?

Liars need to have a good memory, if their lies are going to be believed.

Here's a page that demonstrates that you are lying through your teeth :

http://asp.net.do/test/helloworld.aspx

That page has a button, a label, a textbox and one click event procedure.

I added two Trace.Write statements at "Begin PreInit" and "End Render".

Click on the link above, and see how long it took
for ASP.NET to process and render helloworld.aspx.

Hint : it's about 1.5 milliseconds, not 6 seconds as you claim.

You are a lying troll!



Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

 

[Eliyahu Goldin]

Jason,

You are talking about debugging the business logic module. If I understood
you correctly, you debugged it in a Windows applicaction. To compare
debugging in Windows and web environment is like comparing apples to
oranges, isn't it? BTW in asp.net you also can debug yopur business logic in
a similar way.

Eliyahu

 

[Kevin Spencer]

We are developing applications much slower now (due to the IDE

environment)
and the fact we don't have as much resuable code in asp.net than in the
past,
but we are aiming to harness the features of object oriented programming
which will allow us to develop much faster.

One of the features of OOP is reusability, and a consequence of this feature
is that sometimes it takes awhile to design and implement good reusable
classes. The advantage to it is that once these classes have been (well)
designed, future development in the form of new projects, extension of
existing projects, and maintaining existing projects is much faster.

As for the speed of the IDE, it is a necessary assumption that a developer
should upgrade his/her hardware every few years to accomodate newer
software, which automates much more than older software, and therefore
consumes more hardware resources, especially processor and memory. Of
course, the newer software increases productivity greatly when run on the
proper hardware platform.

Newer technology always has a learning curve associated with it, and the
transition from procedral to OOP is one of the most difficult and
time-consuming to make. This is simply a part of the technological
environment. The farther back from the "cutting edge" you position yourself,
the less this effect will be felt. But competition implies that one should
optimally try to keep abreast of the latest technologies. Still, there are
any number of jobs available for "legacy" developers out there.

All things being equal, and over a period of time, the newer hardware and
technology CAN tremendously increase productivity. It has certainly
increased my own, by leaps and bounds. Less at first, and much more in the
long run.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

 

[Guest]

Why dont you get a real life???

First, If you were as good as you said, you should know or infer the inner
mechanics of VB6 and those of .NET. By the way, VB6 is out of the window.

Bad performance in debbuging time or production just points out some things:

1) You are the typical "Install Windows with wizard": Just next, next ,next
whatever the option is.

2) Your knowledge in "ANCIENT" technologies and "State-Of-The-Art"
technologies is poor.

3) At least try one of those fast tracks with Paul D. Sheriff. He is good at
trainning (as i saw many friends with Sheriff material learning at fast pace).

4) Dont asume everyone has a problem just because you are another VB6-backed
programmer. YES! The kind of programmer that was made just using code wizards
and searching the web just to do something. The kind of programmer that
writes the line but dont understand what the line does exactly at any level.

5) Get a life morooon!!!!

 

[Alvin Bruney - ASP.NET MVP]

can't we all just get along?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



"Win32, VB, .NET n COM Developer" <Win32, VB, .NET n COM
(e-mail address removed)> wrote in message

 

[Guest]

That is the most ludicrous argument I have heard in a long time. Why don't
you factor in the rest of the equation? In VB6 you had to create a DLL which
you had to stop the Web Server to test. You really had no true debugging
environment, so unless you were using VB6 Web Classes, there was no debugging
environment at all.

What about all the other tools you get in .Net? You get a true debugging
environment that works on both client and server side. You are using true
objects, you have a trace facility and the list goes on. I suggest you do
your homework.

 

[Michael D. Ober]

In VB 2005, the background compiler and the dynamic compiler error listing
far outweigh the startup time. In VB 6, I frequently have to compile a
program to get all the compile time bugs out. In VB 2005 with Option Strict
On the compiler also catches almost all my type casting errors as well -
something VB 6 simply cannot do except at runtime. I can't speak for VB 7.x
as I skipped them due to lack of Edit & Continue.

Mike Ober.

 

[Kevin Spencer]

No problem, dude. As I said, we are all humans here, and fallible. I guess
that makes you one of us!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Guest]

The fact that VB.Net and VB6 both contain the letters "VB" is almost all they
have in common, that and clunky syntax.

When you compare the VB6 runtime with the .Net CLR you might as well be
comparing apples to oranges. to draw any type of performance comparison
between them seems silly, because they dont really have much in common.