6

Does anyone know of any documentation on this function, "compile all classes" on the Apex Classes page? I'm finding nothing on help.salesforce.com or elsewhere.

(UPDATE regarding desire to automate at bottom of Question)

I'm being told by a less-than-trustworthy source (the maker of an SF plugin we use) that this is supposed to be used ANY TIME you upgrade an SF plugin. That alone is an overstatement i'm sure, and they are using it to stave off complaints about 1-2 minute Apex routines (processing a single record).

enter image description here

Any insights would be helpful. I'm not sure I even recall seeing this option in my 6+ years with Salesforce products.


UPDATE:   What I'd like is to be able to automatically run the "Compile All Classes" function daily at 6:45am. Being that I'm told by another source (SF Support) that it's declarative, that apparently translates into "it cannot be scheduled". I'd like to believe you can create a class (trigger?) which could be scheduled to run the function on a daily (possibly twice daily) basis. Once again, this is because the maker of a plugin to Salesforce believes this will fix our speed problems in THEIR product).

Scheduling code to run is "easy enough" (console or GUI) but I apparently don't have something that CAN be scheduled to actually run this function.

I am in the midst of testing this, manually running it daily, to see if the performance increase happens... given that this all stems from a Salesforce "Pre-Compile" feature (likely what's being described somewhat in comments below), and that it's now fixed, in our Org, for SF standard objects, but it's NOT doing anything for third party plugins, the hope is that this suggestion to auto run "Compile" each day will solve things.


UPDATE 2:   Salesforce support is "investigating" writing the code necessary to schedule Compile All Classes. If(/when?) I receive this, I will post it as an answer here. (noted on 2017-03-31)

  • I've used it many times, and it is a useful button, but what exactly is your question here? Can you edit your post to make your question more clear? – Adrian Larson Nov 23 '16 at 20:36
  • Surely this button corresponds to the compileClasses() method in the SOAP API. If your vendor requires you to compile all classes every time you upgrade their plugin, that would be a serious cause for suspicion of their code quality. – Adrian Larson Nov 23 '16 at 20:48
  • Absolutely, totally agree, @AdrianLarson. Given it's a plugin with 540 custom objects encompassing over 14k custom fields, and that they have MANY areas needing some serious bulkifying of their code (I'm tired of batch sizes of 1 to 10 during inserts from dataloader).... yeah. (sigh) – AMM Nov 23 '16 at 21:10
7

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, 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 Sandbox or Developer Edition org. For example, given class A and B, if B is called from A, and you delete B entirely or change it, A is invalidated, and has to be recompiled the next time it's called. You can skip this compilation time for the first request after invalidation by forcing a compilation before you need it. This only speeds up the first call to the class after it's been invalidated, as they later use the cache, as explained in the video I linked.

If a piece of code is constantly performing slowly, it is because the code is slow (not optimized/bulkified/whatever). There should only be one "slow load" that occurs after each upgrade, not every single call, or until you "compile all classes." It's a convenience feature that's not often needed, and primarily of benefit during development to speed up load times while testing.

Also, as explained in the video, in the near future, compilation during deployment will occur before the actual deployment takes place, so deployments will take slightly longer, but will reduce the occurrences of the "slow load" that occurs for the first request after an upgrade, because the code will be pre-compiled and only has to be loaded from the cache.

  • your comment makes PERFECT SENSE, and corroborates my feeling that I was being... .mislead... accidentally (cough). I have never, ever, in my life, used that function. While I may appreciate, IF IT IS TRUE that updated code in a managed package STARTS as uncompiled once it arrives, it does not stay that way if it ever gets used. :-P Anyway. Thanks. – AMM Nov 23 '16 at 21:08
  • 1
    @AMM You'll want to watch the video, it's really cool. They explain the two levels of cache as well as a basic overview of how your code becomes a program. It's pretty enlightening. – sfdcfox Nov 23 '16 at 21:10
  • I actually emailed myself the URL to watch it later, thanks. (when i saw it was 40+ min) – AMM Nov 23 '16 at 21:12
  • That video really makes me wonder how much of my problem is "the new compiler" (yes, FASCINATING video, by the way) and possibly Rootstock causing something to needing new caching/compiling, BUT the compiles does not NOTICE it (this is supported by comments Support has made in the last 3 months). Grr. – AMM Mar 30 '17 at 13:14
2

Anytime you deploy code to your salesforce org, be it a managed package update or some custom code, all your classes and triggers are marked "invalid" and must be compiled at some point before they can execute again. For most orgs it is fine to let this occur automatically when the classes are referenced. However, for orgs with a lot of managed code and/or custom code, compiling all classes can improve performance.

Even more important -- for an increasing number of orgs (including mine), some managed functions FAIL TO RUN if there's too much code that needs recompiled during a request cycle. The error message that's returned is that a dependent class is invalid and needs recompiled and the error preventing a recompile is a red herring.

It's at the point where we need to run "Compile all classes" repeatedly and "Compile all Triggers" as well, and then run all our tests and finally the managed package will begin working again. This is a robust, well-know managed package and it is not any fault of theirs. Salesforce has acknowledged the issue is theirs, but have not corrected it yet.

The compile all triggers options isn't available by default. You have to request that it be added to your org if you're having this issue.

0

As far as I recall from the Cloud9 + Salesforce integration, Compile All Classes cannot be called anywhere through the API. Triggering this action through the UI recalculates all dependencies between classes and refreshes the SymbolTables in Salesforce's database. We were looking into it to get accurate auto-completion data for the IDE.

As far as I recall, all of this is done automatically if you edit something through the Developer Console, web interface, or if you deploy, so there's no need to click this link.

  • This answer seems factually inaccurate. There is a SOAP API call for it, and editing one class through the Developer Console absolutely does not compile all classes every time. – Adrian Larson Nov 23 '16 at 20:49
  • 1
    The SOAP API call compileClasses() is not the same as the link in the UI. It actually takes Apex source code as its parameters and works like a synchronous save. You are right in that editing a class in the Dev Console does not recompile all classes, but it certainly does a partial recompilation for the classes you changed. – Alex Brausewetter Nov 23 '16 at 20:56
  • I hope that calling it IS possible - I've just modified the question because honestly, I'm at my wit's end (it's been over six months - the "pre-compile" problem (SF Support Tier 3's words) still exists in NON-SF STANDARD objects (and when you have a now 600 custom object 15k field plugin like Rootstock that is causing the issue, it's anywhere from 1-30 seconds for various responses to happen onscreen in their 100% visualforce pages - I am not sure I believe this is going to WORK, but it's the latest suggestion to try, after over 6 months dealing with it). – AMM Mar 30 '17 at 12:51
0

We were having a similar issue with 2 managed packages each having an object with the same name ('Field_mapping__c'). Although being in separate namespaces, some packaged trigger code querying that object still failed after each managed package update.

Obviously we have asked our managed package providers to hardcode their namespace in their code, but (obviously) that's not a straightforward thing for them to do, and also Salesforce basically states it's not necessary. We've logged a case with Salesforce and they acknowledged the issue but basically end up asking the package providers to change adapt packages (which they haven't done because we seem to be the only one having both packages installed).

After we compile all classes and triggers (via the GUI) it works fine again.

So now we've set up a script in our Continuous Testing tooling that logs in to the production org each morning at 6AM, and presses the 2 buttons. Not very nice but it does the trick, so posting it as an answer here since it might be useful to some.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.