CSharp application slow at startup

  • Thread starter Thread starter Andrea
  • Start date Start date
A

Andrea

I've created an application is CSharp. My problem is that it's very
slow to startup the very first time I run it. The second time it's
much faster. Is this normal? Is there anything I can do to boost its
performance?
Thanks.
Andrea
 
That is normal. NGEN.EXE (shipped with the framework) can help if you
think you need it. Consult .NET tool documentation.
 
Truong said:
That is normal. NGEN.EXE (shipped with the framework) can help if you
think you need it. Consult .NET tool documentation.
Click to expand...

That won't address this issue particularly - if the app is much slower
the first time than the second time it's launched, it's almost
certainly just loading the .NET framework itself which is the killer,
rather than the JITting time.

Jon
 
Then the question is: the app run slowly the very first time it is run
after the computer is turned on, or the very first time after the app
is installed or recompiled on a machine?

I thought Andrea meant the latter; in that case ngen could help.
 
Truong Hong Thi said:
Then the question is: the app run slowly the very first time it is run
after the computer is turned on, or the very first time after the app
is installed or recompiled on a machine?

I thought Andrea meant the latter; in that case ngen could help.
Click to expand...

If it was the JIT compiler it wouldn't matter if it was the first time it
was run after being reompiled or the 20th. JIT Compilation occurs on every
execution unless there is a native image cached through using NGEN

I agree with Jon it sounds like the issue is that the runtime DLLs are
having to be loaded from disk. The OP could put a small .NET .exe in the
startup folder that "warms up" the machine with by loading the runtime DLLs
off disk. Then Andrea's application won't take that hit.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
 
If it was the JIT compiler it wouldn't matter if it was the first time it
was run after being reompiled or the 20th. JIT Compilation occurs on every
execution unless there is a native image cached through using NGEN

I agree with Jon it sounds like the issue is that the runtime DLLs are
having to be loaded from disk. The OP could put a small .NET .exe in the
startup folder that "warms up" the machine with by loading the runtime DLLs
off disk. Then Andrea's application won't take that hit.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
Click to expand...

In fact my problem is that the application is very slow when I run it
the first time (that can be, for example, after recompiling it). Dows
NGen has drawbacks? I remember reading something about it some time
ago.
Thanks
Andrea
 
Andrea said:
In fact my problem is that the application is very slow when I run it
the first time (that can be, for example, after recompiling it). Dows
NGen has drawbacks? I remember reading something about it some time
ago.
Thanks
Andrea
Click to expand...

ngen.exe simply compiles your .exe into native machine code and puts
that code in the cache, so when you execute your .net program again, it
doesn't have to spend time compiling.

I see no downside.
 
jeremiah said:
ngen.exe simply compiles your .exe into native machine code and puts
that code in the cache, so when you execute your .net program again,
it doesn't have to spend time compiling.

I see no downside.
Click to expand...

There are lots of downsides. Look up the documentation in MSDN for a
description of the 'brittleness' of native images (read the Remarks
section):

http://msdn.microsoft.com/library/d...ols/html/cpgrfnativeimagegeneratorngenexe.asp

Here's a good overview, with a list of the downsides of native images:

http://blogs.msdn.com/jasonz/archive/2003/09/24/53574.aspx

Note that the best advice is that you can only tell if native images
will improve your application's performance by actually doing
performance tests. It is not clear from the OP's description if this
would be the case.

Richard
 
jeremiah said:
ngen.exe simply compiles your .exe into native machine code and puts
that code in the cache, so when you execute your .net program again, it
doesn't have to spend time compiling.

I see no downside.
Click to expand...

Downsides:
1) If anything on the system changes (version of framework, processor
etc) the compiled code becomes irrelevant, and will be ignored.
2) NGEN can't perform some of the optimisations that the "normal" JIT
can
3) It's an extra step to perform - added complexity

I'd only consider using it if JITting time was *definitely* an issue
for an application.

Jon
 
Back
Top