What are the advantages and disadvantages of assembly builds in .NET?

What are the advantages and disadvantages of pre-jitting compilers in .NET?

I heard that pre-jitting will improve performance. When should I predict, and when shouldn't I be a predictor?

+4
source share
6 answers

Pre-compiling or pre-compiling will improve performance at startup because you skip this step. The reason that .NET JITs every time the application and its libraries are loaded allows you to run it on many platforms and architectures with the highest possible optimization without the need to manage your builds.

So, you have to weigh whether the admin puzzles are worth it in order to save a few seconds when starting the application and loading the library. I think that the most common use case for this is to install a server where you usually manage several machines and the environment is very stable. For instance. You will not precompile applications for clients because the target environments are much less predictable.

+5
source

Are you talking about NGen to generate assembly images before execution? Pre-JIT is a contradiction in terms, since β€œJIT” means β€œjust in time” as before execution. If you precompile something, it is by definition not JIT-ing.

The advantage is that you do not have the initial compilation delay that JITTER can introduce when the assembly or type is loaded for the first time in the code. For extremely (possibly unreasonable) large assemblies / types, this can be significant.

Disadvantages include things such as the inability to optimize certain things, which can only be determined based on the execution conditions and the fact that you must maintain the image. In addition, all applications and assemblies using pre-generated images (with .NET 4) require full trust, and CAS is ignored.

For more information about NGen, see http://msdn.microsoft.com/en-us/library/6t9t5wcf.aspx

+4
source

"PRE-JIT" is done through NGen (the process of pre-compiling from CIL for your own image). It converts compiled .NET code from a platform-independent middleware state to a platform-specific stage. In plain English, it converts a .NET application that can run on both Windows, Mac, and Linux 32-bit and 64-bit versions into an EXE file that can only work on one of them.

.NET applications are compiled into the intermediate binary format MSIL , which is platform independent. This means that the application can run on any processor on any platform, if the platform supports .NET. What .NET does at runtime is called JIT. JIT will compile the code once per execution before actually using it. It also means that only used code will be compiled.

NGen will give your application a performance boost (mostly launch time), sometimes very noticeable. Everything is safe for NGen as long as you are guided by the correct platform. For example, if your application uses 32-bit DLL files, you should not bind it to 64-bit, and if your DLL file is used by other applications, you should not use it.

I would recommend starting NGen after installation, and not before distribution, so that you know that the application will run on the target computer.

+3
source

This improves the warm start time of your program. A warm start is one where the assembly data is already in the file system cache, so there is not enough time on the disk to search for DLLs on the disk. Unlike the cold start you get when the assembly has never loaded before or has not been loaded for a long time, the drive must first find the file. It is slow. You almost always only care about the cold start time, because the one that is so noticeable to the user.

What is rub, ngen.exe creates an additional file that must be found on disk. One that contains pre-processed machine code (.ni.dll). Perhaps the cold start is slowing down. For "small" assemblies, it actually makes sense to give the JIT compiler jit code, because it may take less time to find the required DLL memory than it takes on disk. What exactly is a "small" breakeven point depends largely on how fast the disk and its fragmentation state can work. You will have to experiment, but keep in mind that this will not repeat well on another machine. And these experiments, like this one, are difficult in themselves, you can easily start a warm start.

+2
source

When you say "pre-jitting", you probably mean using ngen.exe to precompile your assemblies?

Using ngen.exe has no real flaws (except for some additional bytes of disk usage). However, to use it, the assemblies that you want to precompile must be located in the GAC (global assembly cache). However, you will need administrator privileges to obtain them.

Therefore, it is not suitable for applications that you want to easily deploy with Copy & Paste.

Yes, using ngen.exe can improve application performance (even at run time, when some optimizations are skipped during JIT compilation to save compilation time). Therefore, use ngen whenever possible, especially for long-term applications and applications that you really want to install locally.

0
source

I saw an advantage in which determinism of execution is important. Generally, you need to avoid doing timings like the plague. Sometimes this is inevitable. One of the scenarios is the interaction with external equipment, and some of them are asynchronous, especially when there are many steps that are performed sequentially and not repeatedly. This means that each step must be marked, and the hardware simultaneously performs its task (asynchronous communication).

We always use our libraries during installation. Our libraries gain access to disparate hardware devices, many of which were not originally intended for automation.

0
source

Source: https://habr.com/ru/post/1337499/


All Articles