Current filter:
                                You should refresh the page.
                                  • Description:
                                    The first time I run my application which contains the XtraGrid, it takes one to two seconds on my machine to finish loading data. Subsequently it loads much faster 100-200ms. What is causing this performance variation?

                                    Answer:
                                    In .NET, any code requires much more time for execution when being run for the first time. This behavior is .NET specific. When you build your application, it is compiled into the Microsoft Intermediate Language (MSIL). When the application is launched by an end-user, the IL code is compiled into machine code at runtime. This process may cause a noticeable delay. Moreover, the first code execution may require additional DLLs to be loaded, such as the XtraGrid assemblies in your example. Subsequent calls of the same code are performed much faster, because the required libraries are already loaded and the code is already compiled.
                                    Generally, to estimate the performance, build a Release version of your application and launch it from Windows Explorer rather than from Visual Studio. It will run faster when VS is not attached. If the initial application loading is still slow, its thorough profiling is recommended.
                                    If you have noticeable delays in your application due to the JIT compilation and they are critical for your scenario, you may utilize theNative Image Generator (Ngen.exe) tool that ships with the .NET Framework SDK. This tool compiles all of an assembly’s IL code into native code. Then, when an end-user runs your application, CLR loads the precompiled code so that no compilation is required at runtime.
                                    Important notes:
                                    Using NGen requires administrative permissions. Please make sure that you run NGen or the application that invokes it at runtime (see below) as Administrator. In scenarios when NGen should be run on a client machine by a user who doesn't have administrative rights, you can try third-party solutions (AppLife UpdatewyDay, etc.) or create a custom updater. For example, create a Windows service that runs with administrative permissions. When you need to generate native images for new assemblies, send a command to your service so that it can invoke NGen.
                                    NGen.exe must be conservative about the assumptions it makes regarding the actual code execution environment. Therefore, the produced code may not be as highly optimized as the JIT compiler–produced code.
                                    This operation is sensitive to the platform target and CLR version. Here are sample scenarios:
                                    .NET 2.0 +
                                    x86 : C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install C:/MyApp.exe
                                    x64 : C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe install C:/MyApp.exe
                                    .NET 4.0 +
                                    x86 : C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe install C:\MyApp.exe
                                    x64 : C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe install C:\MyApp.exe
                                    In addition, please refer to the following MSDN article, which describes how to generate native images when installing your application on the client machine: Walkthrough: Using a Custom Action to Compile a Binary to Native Code at Installation.
                                    By the way, you may notice that all windows in our demo applications are opened quickly, despite the fact that they contain many DevExpress controls. You can notice the same effect if you compile your own application in the x86 mode and run it on your developer machine. This is the illustration how NGen.exe helps, because our installer automatically installs precompiled native images of DevExpress libraries to the developer machine.

                                    By the way, you may notice that projects with our controls are loaded faster on your developer machine than on the client machine. This is the illustration how native images help.  The native image task generates native images on demand on Windows 8 and later operating systems for assemblies built with .NET Framework 4.5+ installed into the Global Assembly Cache (GAC). DevExpress assemblies are compiled with .NET Framework 4.5.2 starting with v18.2, in previous versions our .NET installer automatically installed precompiled native images of DevExpress libraries to the developer machine.

                                    Alternative approach:
                                    Sometimes, it is impossible to use NGen.exe. For instance, there is no out-of-the-box way to process an application with NGEN when you deploy your application using ClickOnce. There is a workaroundwith calling NGEN directly from code:

                                    [C#]
                                    static class Program { /// <summary> /// The main entry point for the application. /// </summary> [STAThread] static void Main() { if (ApplicationDeployment.IsNetworkDeployed && ApplicationDeployment.CurrentDeployment.IsFirstRun) { string appPath = Application.StartupPath; string winPath = Environment.GetEnvironmentVariable("WINDIR"); Process proc = new Process(); System.IO.Directory.SetCurrentDirectory(appPath); proc.EnableRaisingEvents = false; proc.StartInfo.CreateNoWindow = false; proc.StartInfo.WindowStyle = ProcessWindowStyle.Hidden; proc.StartInfo.FileName = winPath + @"\Microsoft.NET\Framework\v2.0.50727\ngen.exe"; proc.StartInfo.Arguments = "uninstall " + Application.ProductName + " /nologo /silent"; proc.Start(); proc.WaitForExit(); proc.StartInfo.FileName = winPath + @"\Microsoft.NET\Framework\v2.0.50727\ngen.exe"; proc.StartInfo.Arguments = "install " + Application.ProductName + " /nologo /silent"; proc.Start(); proc.WaitForExit(); } Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } }

                                    Starting with the .NET Framework 4.5, you may use the System.Runtime.ProfileOptimization class. This class will help you specify what methods to call to get JIT compiled. Then, when an end-user runs your application again, the JIT compiler will compile these methods using background threads (if the target machine has multiple CPUs). As a result, the application may run faster because multiple methods get compiled concurrently during the application initialization (instead of compiling the methods when an end-user is interacting with the application). So, you will have some delay at runtime, but at the expected moment.
                                    Here is sample code:

                                    [C#]
                                    ProfileOptimization.SetProfileRoot(@"C:\MyApplication"); ProfileOptimization.StartProfile("Profile");

                                    Please refer to the following articles for more information:
                                    https://msdn.microsoft.com/en-us/magazine/hh882452.aspx
                                    https://blogs.msdn.microsoft.com/dotnet/2012/10/18/an-easy-solution-for-improving-app-launch-performance/

                                    For older .NET versions there is an approach described in Liran Chen's Blog:
                                    Forcing JIT Compilation During Runtime
                                    This approach uses the PrepareMethod, which has the following note in the .NET Framework 2.0 documentation:
                                    The classes in System.Runtime.CompilerServices are for compiler writer use only.
                                    However, in further .NET Framework versions, this note was removed. In any case, it is up to you whether to use this approach or not.

                                    See Also:
                                    Boosting the Performance of the Microsoft .NET Framework
                                    Performance Considerations for Run-Time Technologies in the .NET Framework
                                    Improving Application Startup Time
                                    JIT methods at runtime

                                • Alex Miller 01.26.2017

                                  Hi Dimitros,

                                  That Multicore JIT is no joke, it just shaved 2 seconds on my app startup time!

                                  Thanks for pointing this to us.

                                  Alex

                                • Dimitros (DevExpress Support) 01.26.2017

                                  I am happy to hear that, Alex!

                                0 Solutions

                                Creation Date Importance Sort by