Can you "Prime" your .Net application?

[Denaes]

You know how the first time you run certain things, it runs really slow?

 

Yeah, thats a nice first impression.

 

But after the first time something is used, it works like butta.

 

Is there a way to prime your intensive procedures up front while a splash screen is showing? Maybe open said forms, run certain procedures once in the background while everything is starting up.

 

I mean, heck. .Net (and my app in particular) starts much faster than most regular apps I have which have a splash telling you "loading XXX.dll, XYZ.com, etc"

 

You could just throw up a "Initializing program" message. When it starts up, it would run mad fast.

[techmanbd]

I think this is what you atre asking. Make a new form for your splash screen. You don't need to do any code in that form and then do something similar to the code below. The "frmController_Load" sub is in my main form

And I used a progress bar on the splash for but you can us a label and have the label say what it is loading.

 

  Private Sub frmController_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
       Dim frmSplash As New frmSplash
       frmSplash.Show()
       Application.DoEvents()
       frmSplash.pgbLoad.PerformStep()
      'code here to run for loading something
       frmSplash.pgbLoad.PerformStep()
      'code here to run for loading something
       frmSplash.pgbLoad.PerformStep()
       drmSplash.Label1.text = " Loading ****.DLL" 'example of label
      'code here to run for loading something
       Me.addtextarray()
       frmSplash.Dispose()
    
   End Sub

[iebidan]

The best way to do things is to use the multithreading capabilities of .NET, while you're running your app in the background you can be running an update procedure or maybe the spell checker.

Multithreading is the solution for many SLOW things

[akiaz]

See this for how to "keep alive" an asp.net application:

 

http://authors.aspalliance.com/PaulWilson/Articles/Default.aspx?id=12

[Arch4ngel]

What is the point ?

Not even in the topic ! :p lol ;)

[Nerseus]

My company uses a 2 EXE approach. One exe, the "loader", runs and shows a splash screen/progress bar. It reads from a config file and "downloads" DLL's, EXE's, etc. (checks versions and more) then launches the main EXE (which may show it's own splash screen, but generally shows a login box first).

 

The "loader" can even download a new loader if needed (don't ask me how - I didn't code it!).

 

I assume you're trying to show something while your app is "loading" but before any code has run. This is just one approach, but a simple splash screen inside your app may work well, too.

 

-ner

[Denaes]

The best way to do things is to use the multithreading capabilities of .NET, while you're running your app in the background you can be running an update procedure or maybe the spell checker.

Multithreading is the solution for many SLOW things

 

I'm not just talking about slow things, but how the first time you do anything in .Net, while it compiles JIT, it's slower. After it's been run once it works fine. The first time you can wait 2-5 seconds for a form to load. Its not that long, but when someone just paid 10,000 to upgrade their program to .Net, they don't want it going slower than the old Delphi/C++ version.

 

After the first time, it only takes a split second to load.

[Denaes]

I think this is what you atre asking. Make a new form for your splash screen. You don't need to do any code in that form and then do something similar to the code below. The "frmController_Load" sub is in my main form

And I used a progress bar on the splash for but you can us a label and have the label say what it is loading.

 

This might be what I'm looking to do, but I don't know how to do the loading.

 

How to you prime/run code (causing it to compile) for a form while it's in the background, before the main app has started?

 

Can you start the app in the background and while it's not visible (but still running) open up other not visible forms?

[PlausiblyDamp]

You may also want to investigate the command line tool ngen.exe, this will precompile your .Net assemblies into native machine code and avoid the overheads of the JIT compile. However it may not always be the best option.

[Denaes]

You may also want to investigate the command line tool ngen.exe' date=' this will precompile your .Net assemblies into native machine code and avoid the overheads of the JIT compile. However it may not always be the best option.[/quote']

 

Yeah, I read about fully compiling your code...

 

Right now it might be a better short term "Patch" to avoid a real solution.

 

the Framework is clownshoes right now. It has potential for MS (or whoever) to truely optimize it to run apps specifically optimized for each proccessesor type.

 

When/If they ever do what needs to be done with the framework (like making it multi-platform or really optimizing for different proccessors), it would be downright stupid to precompile your program.

 

From what I gather right now, you gain more speed up front, but that might cost you a little speed after compilation because the JIT supposedly optimizes the code for the situation.

 

I might do that since the demo date is approaching and I don't know how to do it the correct way, but I do need how to do this properly at some point.

[Nerseus]

Depending on the type of demo, maybe you could "prime" the app on the demo machines before the end users do their testing? Or if it's a bigger release, you could let your implementation team know the details and pass that along.

 

A good explanation may go a long way, especially if they hear that the app is optimizing itself the first time through so be patient, and they'll get the rewards from then on.

 

-Nerseus