Making .net Applications Run Faster

  • Thread starter Thread starter Manu
  • Start date Start date
M

Manu

Hi!

How can i make the .net applications run faster on user computers. I have
used .net a lot and proagrammed int it. But the applications developed using
..net framework are very slow when compared to other progrmming tools like
VB6.
 
Are you doing a lot of string concatenation? If you are, you should be
using a StringBuilder class instead. In .NET, string concatination creates
new strings. Lots of string concatination requires a lot of copying of
strings and creates a lot of garbage. Lots of garbage requires frequent
garbage collection, which slows things down.

Also, be sure that you aren't deploying a debug build of the application.
Debug builds prevent the CLR JIT compiler from performing many
optimizations.

You might also want to watch this episode
(http://msdn.microsoft.com/theshow/Episode027/default.asp) of the .NET Show
on MSDN. They talk about opitimizing .NET code. The chief topic is how the
garbage collector works and how you should code accordingly.
 
..net applications will generally run faster that VB6 applications,
unless they are natively compiled. I would strongly recommend using
tools like DevPartner to find performance bottlenecks in your application
 
Scott English said:
Also, be sure that you aren't deploying a debug build of the application.
Debug builds prevent the CLR JIT compiler from performing many
optimizations.
Click to expand...

No they don't - running any code in the debugger does.
 
True, attaching the debugger *really" slows things down, but even a debug
build will prevent the JIT compiler from performing optimizations. The
debuggable code needs to be in a format that can be correlated with the
source code. This prevents the JIT compiler from performing many
optimizations. Even if the debugger isn't connected to the application when
the code is running, the JIT compiler has to compile the code such that a
debugger could later be attached (otherwise, you wouldn't be able to attach
a debugger to a running application and debug it).

See http://msdn.microsoft.com/theshow/episode020/TranscriptText.asp and
search for "debug" and "optimize".
 
Scott English said:
True, attaching the debugger *really" slows things down, but even a debug
build will prevent the JIT compiler from performing optimizations.
Click to expand...

Not in my experience.
The debuggable code needs to be in a format that can be correlated with the
source code.
Click to expand...

Well, there just needs to be an extra file (the pdb)...
This prevents the JIT compiler from performing many
optimizations. Even if the debugger isn't connected to the application when
the code is running, the JIT compiler has to compile the code such that a
debugger could later be attached (otherwise, you wouldn't be able to attach
a debugger to a running application and debug it).

See http://msdn.microsoft.com/theshow/episode020/TranscriptText.asp and
search for "debug" and "optimize".
Click to expand...

Well, that's using the specific example of cordbg (assuming I'm looking
at the same piece that you are) - but even then it says that you can
tell cordbg to enable optimisations, even on that code which has been
compiled in debug mode.

Can you provide a benchmarking example which displays this behaviour?
In other words, which when compiled with debug information but launched
directly from the command line takes longer to execute than the same
code compiled without debug information? (Without resorting to things
which generate stack traces.)
 
Thanx Scott!!

I have found some informaion on the .net framwework's site. Under the
performance section.
 
I've just done some benchmarking myself, and I entirely withdraw my
comments. You're exactly right - it can make a huge difference.

Sorry!
 
Back
Top