text: In most situations with fully AOT compiled programs and libraries, it is possible to remove part of a runtime environment, thus saving disk space, memory, battery life, and startup times (no JIT warmup phase), etc. Because of this, it can be useful in embedded or mobile devices.
  Performance trade-offs
  AOT compilers can perform complex and advanced code optimizations which in most cases of JITing will be considered much too costly. In contrast, AOT usually cannot perform some optimizations possible in JIT like runtime profile-guided optimization (PGO), pseudo-constant propagation, or indirect-virtual function inlining. AOT must compile to a target architecture while a JIT can compile the code to make the best use of the actual CPU it is running on, even years after the software has been released.
  Further, JIT compilers can speculatively optimize hot code by making assumptions on the code. The generated code can be deoptimized if a speculative assumption later proves wrong. Such operation slows the performance of the running software until code is optimized again by adaptive optimization. An AOT compiler cannot make such assumptions and needs to infer as much information as possible at compile time. It needs to resort to less specialized code because it cannot know what types will go through a method. Such problems can be alleviated by profile-guided optimizations. But even in this case, the generated code cannot be adapted dynamically to the changing runtime profile as a JIT compiler would do.