Peek Under the Hood of the New Apex Compiler
Why Salesforce Stack Exchange recommends it
Salesforce Stack Exchange answerers point people to it for an authoritative explanation of how Apex is compiled, cached and executed, especially when debugging slow first calls, stale classes or deployment effects.
Recommended by 4 people across 8 different months, 2016 to 2022.
What it is
A Dreamforce 2016 session from Salesforce Developers on the then-new Apex compiler. It covers on-demand compilation, what gets compiled and stored where, the caching strategy, and why and how the compiler was rolled out.
What people said
Recommends sfdcfox · 2016-11 · Salesforce Stack Exchange · on “Compile All Classes?”
The ability to Compile All Code has been around as long as Apex Code has been a thing. You'll want to watch Peek Under the Hood of the New Apex Compiler [this video] , a Dreamforce 16 presentation that was later uploaded, that explains basically how the system works today, as well as plans for the near future. To summarize the video though, code is compiled mostly "on demand", and generally occurs the first time some code requests a class has that expired from the caches, usually because it has been modified or one of its dependencies have been modified. Generally speaking, though, you don't usually need to use this feature in production. It's primary benefit is for use during development in a Sa
Recommends sfdcfox · 2017-08 · Salesforce Stack Exchange · on “Slow Javascript Remoting on First Call”
You'll want to watch this DF presentation [this video] that explains a bit about the stuff that happens in the platform. It'll explain quite a bit about what Eric is saying.
Recommends sfdcfox · 2018-01 · Salesforce Stack Exchange · on “What happens internally when a program is compiled? and when We hit RunTest Button?”
When you call the RunTest command, the system first checks the local code cache for valid byte code. If it fails to find it there, it then checks the pod-wide shared code cache; if the code is there, it's loaded locally and stored in the local cache. If that fails, it then retrieves your source code from the database, compiles it to byte code, and places a copy in the pod-wide shared cache and local cache. Once the byte code is available, it then runs the code. The Apex Code execution system is a type of VM like Java, with hooks into various Java libraries-- a process called marshaling-- to help improve the performance of the code when possible. It's also responsible for things like checking
Recommends battery.cord · 2018-03 · Salesforce Stack Exchange · on “How to explain hidden/undocumented properties off of SObjectType?”
Pretty much, yeah. Stuff like `@isTest`, "`Account` type binds to `Schema.Account` when namespace is null or empty" (from apex winter '18 compiler changes [LINK] ).. I'm sure theres a lot more, but a lot of it is under the hood, and not usually discussed - you'd have to talk to someone at salesforce to get the full scope of the compiler. If you want to learn more, check this video out: [this video]
Recommends battery.cord · 2018-04 · Salesforce Stack Exchange · on “Apex method signature change does not reflect”
Yeah, sounds like its accessing a cached class which hasn't been updated yet. This is an old youtube video [this video] which goes into detail about how apex caching works. It doesn't cover lightning, but might at least help you understand whats going on behind the scenes. Changing the return was more to test if the parameters were being messed up somehow, or if a old function was being called. Only other thing I can think of is that something in your build process or IDE isn't deploying properly ..
Recommends Daniel Ballinger · 2019-07 · Salesforce Stack Exchange · on “What is `apexCache` and `apexCacheWarmer` in tooling API?”
If you cast your mind back to Dreamforce 2016 Josh Kaplan did a talk on the new (at the time) apex compiler. See Peek Under the Hood of the New Apex Compiler [this video] . It included details on how compiled apex is cached for use on the app servers. [LINK] ApexCache and ApexCacheWarmer are almost certainly related to that functionality. I checked with Chris Peterson. Further details: They are scratch org specific. At least in terms of being exposed by the API. They are used by the SFDX test run command to tell if apex is compiled and/or cached. This is taken into account for how long the tests take to run. The documentation is coming in the future.
Recommends sfdcfox · 2019-08 · Salesforce Stack Exchange · on “force:package:install --apexcompile package --- what are the pros/cons of using it”
By default, Apex Compilation is off for Sandbox, Scratch, and Developer Orgs, while it is turned on for Production Orgs. How Apex is executed has been described in several Dreamforce sessions, such as Peek Under the Hood of the New Apex Compiler [this video] . It's a rather long watch, but I dare say it'd be insightful. That said, here goes: force:package:install --apexcompile package Pros Minimizes installation time, as only the package's code will be compiled. Cons Loading times for dependent code will be longer the first time it is used after installation. For example, if A uses B, and B is upgraded as part of a package, then A will not recompile until the next time it is used. Dependent code
Recommends Jeferson Chaves · 2022-09 · Salesforce Stack Exchange · on “Do deployments affect end users? (performance)”
Hello Piotr - I think this video can help you clarify some of your questions and relates to what Derek F mentioned (I heard something like this at Dreamforce once). Btw this is a bit old 2016: [this video] In general unit tests should not slow down performance, but deployments can.