Why does it take so long to start an application in debug mode?

[VaxoP]

it must be 50x slower than vb6. in vb6 you click play the form appears

here it goes thru each dll every single time and its such a pain to watch it do all that when all you did was change one simple line of code.

vb.net is supposed to help us make applications faster, but why does it do it so slowly?

is there something im missing? maybe an option to make it load up faster?

[Edneeis]

There is a big difference between what happens in VB6 and .NET when you press 'play'. VB6 didn't actually compile the code it until you made the exe instead it would interpert(sp?) it at runtime and run it as part of the VB6.exe. This is faster but then you are debugging code that is actually not the same as the final exe and sometimes you would experience errors in the exe but not in the debugging because of this. .NET is like most other languages and compiles even during debugging and that is what you see going through all the parts of the project. The faster the computer the faster the compile, but you wont have any errors in the exe that didn't pop up during debugging since you are debugging the exe itself.

[VaxoP]

is there any way for .net to not do that?
im on a duron 1300 on a os that i havent formatted in 2 years (xp) with 468mb sdram..

it takes FOREVER do to anything with .net

[Cander]

No.

Quite frankly your problem, based on your other posts, is probably all the COM interop your are using trying to use ActiveX in .NET.

The .NEt does not inherintly support ActiveX and has to create wrappers for those when it compiles.

[VaxoP]

i dont get it - its lik 10x faster to build the project then to debug it..

argh

[Pirate]

I agree with that VB6 proj is faster than VS.NET's . I dunno exactly why but it looks like this huge .Net Framework has some part in this slowness . I discovered that after deploying my proj and running it on different PCs and got almost the same results .

[PeteD]

make it faster by not including as many projects in one solution. i.e. just reference the dlls. Also, get a faster pc!

[Desbaratizador]

Visual Studio .Net 2003 is better than 2002

[Pirate]

Originally posted by PeteD
Also, get a faster pc!

. Me , ok I have fast PC , but what about other users . Do you want me to tell them to get faster PCs . It's not a solution yet .

[Kasracer]

Originally posted by VaxoP
is there any way for .net to not do that?
im on a duron 1300 on a os that i havent formatted in 2 years (xp) with 468mb sdram..

it takes FOREVER do to anything with .net

Time to format. Most people recommend formatting atleast once a year especially if you're doing high end things.

Also, your system is quite out-dated, maybe time for an upgrade?? The more ram the better with XP and .NET

Originally posted by Pirate
. Me , ok I have fast PC , but what about other users . Do you want me to tell them to get faster PCs . It's not a solution yet .

I still have yet to experience slowness with any .NET applications.... they all seem to run as fast a normal.

Granted Pure C++ code will run faster than VB or any language using the .NET framework because the program has to go into something to get the information and bring it back to work with it. So it will never be the fastest thing, but computers are becoming so much more powerful, no one will even notice anymore.

I seriously can't tell the difference between most .NET applications and native applications (unless I don't have the framework installed and it bitches at me)

If you want serious speed, I'd suggest learning C++ and not touching the .NET framework.

a hell of ALOT more work involved, but it would be alot more optimized and not require the framework.

DLLs have alot of ups and downs. They are good to keep things organized and to update parts of programs, but they are not the fastest things by all means and they just add another dependancy.

[PeteD]

Originally posted by Pirate
. Me , ok I have fast PC , but what about other users . Do you want me to tell them to get faster PCs . It's not a solution yet .

Tell them what you like! My p4 1.7 512MB work machine compiles and starts up the same solution in the IDE almost twice as fast as my p3 800, 256MB home machine. Developers time = money, so a new fast PC would pay for itself over time. The length of time it would take to pay for itself would depend on the rate/hour of the developer. Say a contractor is on £35/hour (or whatever), you wouldn't want him twiddling his thumbs waiting for a slow PC to compile something!

[Hu Flung Dung]

Your on a duron 1.3 GHz with over 400 megs of ram, and VS is slow?

Hmm, I've a 1.4 p4 with 256 megs, and my shoot'em up game (which is quite large mind you) takes only about 3 seconds to compile in VS 2002. I don't understand why it takes so long for you.

[Kasracer]

Originally posted by Hu Flung Dung
Your on a duron 1.3 GHz with over 400 megs of ram, and VS is slow?

Hmm, I've a 1.4 p4 with 256 megs, and my shoot'em up game (which is quite large mind you) takes only about 3 seconds to compile in VS 2002. I don't understand why it takes so long for you.

He hasn't formatted in 2 years, which is probably his main problem.

That and I'm sure he has a ton of crap installed, maybe even spyware and stuff slowing his machine down

[Hu Flung Dung]

Originally posted by kasracer
He hasn't formatted in 2 years, which is probably his main problem.

That and I'm sure he has a ton of crap installed, maybe even spyware and stuff slowing his machine down

I never format my drive unless I've a serious problem or do a major system upgrade (its probably been 2 years for me too), and I have tons of games, utils, and development tools installed.

Perhaps his drive needs to be defragged?

[Doorstep]

What I find really helps is this:
Create a shortcut on your desktop to the debug version that gets compiled e.g. Project\Src\Bin\DebugExe.exe. When you are working in the code window of your project and you compile you will notice how fast it compiles. After compile, minimize the VB.net IDE and run the shortcut to your debug executable. I found doing this really speeds my debug and build cycle, and I'm using a PIII-450 with 256MB ram (plenty fast for what I do because I spend most of my time writing code).

If you simply 'Play' the project using F5, VB.Net shell executes your app after compilation completes, and if you've been programming for a while (like most of your life), you'll realize that shelling out and executing anything from anywhere usually slows things down.

One other thing I have found...
Whenever I switch between the designer and source code it literally takes FOREVER to finally switch from one to the other, especially if I modify even a single object in the form designer. I suspect it's because VB.Net regenerates the entire section of " Windows Form Designer generated code ". Take a look in this code region and you will see lots of **** and will understand WHY it takes so long.

Hope this answers your question.

Cheers

[Andy]

I have to say, I'm getting un-impressed each day with silly things like this. I have 1Gig of ddr ram (3200), 3 ghz intel p4, and a whopping 128MB video card. It takes a little while for my program to launch in debug mode as well. It REALLy gets to me when I make a change in the editor, switch over to design view and have to wait 30 seconds for the IDE to do whatever it is doing. I posted this complaint once. There are MANY bad bugs in the 2003 (oh yeah, that's the version I'm running) that make it hard to develop in a timely manner.

We have a problem with our work not getting saved. I think that has been linked to the fact that we all save our projects to a central server over a network. Another bug is the annoying tab shuffle. I could go on but it's old news actulally.

All we can do is wait and pray M$ will pay attention to the people who have paid good money for the product.

just my .02