App speed

I found a few old threads dealing with VB.Net speed, but many of them pertained more to the speed of the IDE.
I've got about a dozen machines, all running W98, that only have 32 mb RAM. A few others have 64 mb, and a few have 128 mb.
Although the current app I have them running is fairly small, around 1200 lines, it takes 12 -15 seconds for the app to load on the 32 mb machines. Is there anyway to speed this up, other than installing more RAM? They're not retrieving thousands of records in the Load event or anything. Thanks.

No, .NET languages are compiled at execution time and that is why they're slow to first start up.

As long as you don't shut down the system, it will cache the program partially so it will be quicker to startup the second time. However, there is a compiling engine that will always run while the program is running.

I'd suggest reading up on the framework and especially JIT.

I've never done it before, and I don't know how to do it, but my understanding is that there is a way to set up your project so it compiles to Machine Code at install time, instead of runtime.

It's mentioned on this page, but it does not say how to do it.. http://www.edgequest.com/clr.aspx

Well, that's what I thought, but even so it seems like a long time. It's hard for me to test for that on my machine w/a half gig of RAM and better processor.

Quote:

---

Originally post/ed by Dmyze
I've never done it before, and I don't know how to do it, but my understanding is that there is a way to set up your project so it compiles to Machine Code at install time, instead of runtime.

It's mentioned on this page, but it does not say how to do it.. http://www.edgequest.com/clr.aspx

---

No that is currently impossible.... well until the Salamander compiler comes out.

BTW, that article has a bunch of inaccuracies in it, it's best to read the one off the MSDN. It also doesn't mention the ability to compile your projects down into Machine Code. It was just explaining (half-assedly) how the framework works.

There is a way to convert the code from IL to native code which boosts the application execution but with some limitations on reference issues and embedded stuff if I can recall it . Read that in the MSDN Help file .

it doesn't say how to do it..

http://msdn.microsoft.com/library/de...ompilation.asp

"The runtime supplies another mode of compilation called install-time code generation. The install-time code generation mode converts MSIL to native code just as the regular JIT compiler does, but it converts larger units of code at a time, storing the resulting native code for use when the assembly is subsequently loaded and run. When using install-time code generation, the entire assembly that is being installed is converted into native code, taking into account what is known about other assemblies that are already installed. The resulting file loads and starts more quickly than it would have if it were being converted to native code by the standard JIT option."

Quote:

---

Originally posted by Pirate
There is a way to convert the code from IL to native code which boosts the application execution but with some limitations on reference issues and embedded stuff if I can recall it . Read that in the MSDN Help file .

---

ngen.exe to convert to native. The only thing I think you lose is any benfits the JIT compiler gives you like debugging.

Humm.. maybe this is how you do it.

http://msdn.microsoft.com/library/de...stallation.asp

Quote:

---

Originally posted by Cander
ngen.exe to convert to native. The only thing I think you lose is any benfits the JIT compiler gives you like debugging.

---

I just checked out ngen.exe. It will create a native image to be used in debugging, it won't create one for everyday use.

Creating an image of a program isn't the same as compilg it into native code.

Currently, no program or item in the framework exists to compile down a .NET application into native code. Salamander's mini-deploy is probably the closest thing. They do plan on making a compiler to take it down to native code, but who knows how that that'll be before even a beta comes out.

Quote:

---

Originally posted by Dmyze
Humm.. maybe this is how you do it.

http://msdn.microsoft.com/library/de...stallation.asp

---

Looks to me like it just compiles and caches part of the program to make it load a little bit quicker, not compile down to native. This may be an answer for our thread starter.

ngen will create a native image for everyday use. You seem to be mixed up. Even the local MS rep told us to use it if we need to solve the jit slowness when it compiles things.

And just to back that up, here:

Quote:

---

Running Ngen.exe on an assembly allows the assembly to load and execute faster, because it restores code and data structures from the native image cache rather than generating them dynamically.

---

Quote:

---

A native image is a file containing compiled processor-specific machine code. Note that the native image that Ngen.exe generates cannot be shared across Application Domains. Therefore, you cannot use Ngen.exe in application scenarios, such as ASP.NET, that require assemblies to be shared across application domains.

---

Quote:

---

If you run Ngen.exe on an assembly that has a debuggable code attribute, depending on the attribute's flags, the tool automatically generates code as if you had specified the /debug or /debugopt options.

If Ngen.exe encounters any methods in an assembly that it cannot generate, it excludes them from the native image. When the runtime executes this assembly, it will revert to JIT compilation for the methods that were not included in the native image.

---

Those are from this link, which is just one of many that explain the tool.
http://msdn.microsoft.com/library/de...torngenexe.asp

Quote:

---

Originally posted by hellswraith
ngen will create a native image for everyday use. You seem to be mixed up. Even the local MS rep told us to use it if we need to solve the jit slowness when it compiles things.

---

When I ran the tool, it didn't show all the options the MSDN is showing, so I stand somewhat corrected.

It still won't create a native exe, it just pre-compiles the program for that specific machine and stores it in the cache just like the installation a few posts up.