Application Startup Performance

  • Thread starter Thread starter Simon
  • Start date Start date
S

Simon

Hey gang.

First off I want to say thanks for all the efforts on the NETCF. I really
love the library set.

I am a mobile developer who works on 3 major mobile platforms
(WM/BlackBerry/iPhone) and by far .NET is my most experienced platform for me
however our applications start up time is far longer on NETCF than the other
2 platforms.

I really want to eliminate the "slow WM" perception and I really think it
relates to our application start up time because I think once the app is up
and going it flies through some seriously impressive amount of code. NETCF2
really improved huge performance in this regard.

No other SDK comes even close to NETCFv2+. Seriously the best SDK.

However application start up is taking around 10-14 seconds of the spinning
cursor until the Main() methods first line occurs in our application.

What kinds of things can I improve on to reduce this?

Perception is reality sadly. The iPhone does not have super fast app loading
either, but they do some hacky things to improve the "perception". I doubt
I'm able to publically discuss this because of their license agreements
however ;)

I really want to try and improve this experience if possible. I am thinking
of taking any code out of the Main() and constructor so that a window can pop
up as fast as possible, and then do loading.

People want to see the "window" pop up ASAP generally, or else they consider
it slow, even if a wait cursor occurs once the window has shown.

However it takes 10-14 seconds to hit the Main method, so what kinds of
things can cause this?

I imagine straight up amounts of code the JIT has to munch through is one
factor. Is there anything programatically I can do to relieve this?

Are static objects being allocated at this point and increasing the loading
time?

Any help would be greatly appreciated!

Thanks and take care,
Simon
 
If you're app is the first one on the system being executed by the CLR, then
the delay could largely be due to the CLR starting up.

To test this theory, start the app, then close (really close it), and then
start it back up, does it still take 10-14s?

The other major factor I've seen is referencing a lot of assemblies other
than those included in the CF BCL. Each assembly you reference will delay
the startup. Having fewer, but larger, assemblies is better than many small
ones.

If this is the case for you, try combining as many as you can into a single
assembly. Using ILMerge may be a possibility here, but I haven't tried it.

-Drew
 
You may also be doing a bunch of other data setup during startup. We can't
really tell you what's going on unless you tell us what your code does.
However, if you are, for example, opening a database connection or loading
some bitmaps for use by the program, etc., those would naturally be part of
the problem. None of my programs, other than those that open database
connections, take anything like that long. How long does it take to start
up a simple Hello, World application on the device? That's the best you can
do. If it's 12 seconds, you're stuck, unless you want to switch to native
code. I'd bet that a look through your code will show you tons of things
that are done on startup that could be done in a background thread to
improve user experience.

Paul T.
 
Hello,

another thing is: if your app. has many forms and you pre create them at
startup it will lead to such things as well.

You might create a splash screen of some sort.
Or do some of your initializations from a timer started off Main.

Greetings

Markus
 
Thanks everyone for the replies!

I fully understand that any code I am doing on app start up reflects the
user experience however I wrote the following:

"However application start up is taking around 10-14 seconds of the spinning
cursor until the Main() methods first line occurs in our application.

What kinds of things can I improve on to reduce this?"

If I wasn't making sense here what I mean is it takes this long just for the
Main() method to be hit. Before any user code has executed.

That is why I am asking what other things less obvious effect start up
performance in the CLR.

Do static objects get allocated before Main()? What can my written code do
to impact performance pre-Main() execution is what I'm getting at.

Multiple assemblies is a good thought. I went through the ILMerge for the CF
and it shaved less than a second off the start up time so virtually no
difference.

A blank form pops up in 3-4 seconds I believe. I'm sure assembly size has
something to do with JIT length of time however I am a firm believer perhaps
I am abusing something which is causing more things to occur in the CLR and
if I can minimize this, it would be great.

Like I mentioned, do Statics play a role in pre-Main() performance?

Thanks everyone and take care,
Simon
 
Yes, static objects get allocated on startup. If you're doing

private SqlCeConnection sqlConnection = new SqlCeConnection( <connection
string> ).Open(), etc., etc.

that would be bad. I would guess that what you're seeing mostly is the size
of your assembly that contains the startup classes.

Paul T.
 
Paul thanks so much for the reply!

What about if the static isn't initialized in the declaration and it is
initialized in the static constructor? In VS this constructor doesn't fire
until the static is "accessed" so it doesn't seem like its allocating on
start up but like I said I don't know whats going on in the CLR.

Something such as:

public class MyApplication
{
private static IocContainer container = null;

static MyApplication
{
container = new IocContainer();
}
}

Would this be an issue?

As far as assemblies I have:
EXE 95KB
DLL #1 13KB
DLL #2 46KB
DLL #3 103KB
DLL #5 10KB

Does this sound "heavy"?

I really like your idea of thread loading some stuff in the BG but right now
I think I am battling a JIT thing here or misuse of some objects causing the
app start to be more involved than perhaps it needs to be.

In comparison to our other mobile applications such as j2me for blackberry
and such the app is about half the size and they start ~1 second on those
devices. I'm really trying to trim this start up time down so we get
presented with some sort of window as quickly as possible.

Hopefully I can achieve this :)
 
Have you tried to start debugging on the app with a "Step Into" instead of a
run? That will get you to the first line of executed code, be it static or
whatever.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
Hi,

Simon said:
What about if the static isn't initialized in the declaration and it is
initialized in the static constructor? In VS this constructor doesn't fire
until the static is "accessed" so it doesn't seem like its allocating on
start up but like I said I don't know whats going on in the CLR.
Click to expand...

See the article titled "C# and beforefieldinit" at
http://www.yoda.arachsys.com/csharp/beforefieldinit.html for more details on
expected behaviour and what is specified in the C# / CLR specifications vs
current implementation specific behaviour etc.

As Chris Tacke suggested the easiest approach to diagnose these sorts of
issues however would be to introduce logging and/or use the debugger to step
into the startup code.

Hope this helps,
Christopher Fairbairn
 
Read up on the items referenced by Chris and Christopher. I would just set
any suspicious globals or statics to null, not to some actual object.
Allocate and assign them in Main. That should tell you whether it's you or
the CLR that's mostly at fault.

Paul T.
 
Back
Top