Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
I have a Visualforce page that, once an action method is called, performs lots of calculations and then displays data on the page.
I am hitting the synchronous heap size limit of 6MB and I want to leverage asynchronous processing so that I can increase the heap size to 12MB.
As @future methods are void, what approaches can I take to refactor my constructor to be able to bypass the 6MB limit?
Two possible approaches are possible if you simply can't get past the limits.
First, you can do client-side rendering and calculation with RemoteAction methods or Remote Object invocations to get the data you need. This is generally acceptable if you're looking at a significant amount of data, and it gets really good performance, as JavaScript is far faster than Apex Code. RemoteAction methods can return 15MB of data, and you're not likely to hit the heap limit since the execution time would be short.
Second, you can do asynchronous processing, but you'll need some Queueable code. Use System.enqueueJob to start the processing, and get the Job ID. Then, poll the server until the job reports as completed, then finally query the data back from the database. Note that this means you'll need to arrange a mechanism to determine where the results were stored. It's certainly complicated, but possible.
I think you need to live within the 6M limit.
The first thing to do though is to understand what is taking up the space by reviewing your code and thinking about the likely sizes of what you are outputting. (A classic extreme example is querying the body field of Attachments where each body can be up to 5M in size.) You may be able to compromise with what you output e.g. only showing the first 80 characters of strings that could be many thousands of characters long.
Also be aware of Setting Read-Only Mode for an Entire Page thst helps with other limits.
Your intermediate steps my be causing the heap problem. A couple of examples...
Patterns such as this SOQL For Loop:
for (MyType__c t : [select ... from MyType__c ...]) {
...
}
avoids heap space being occupied by all the records queried. Instead the records are queried in batches.
You can also discard intermediate results as soon as they are no longer needed:
List<Something> bigList1 = ...;
List<Something> bigList2 = ...;
List<Something> intermediateResult = ...;
bigList1 = null;
bigList2 = null;
// Heap space for bigList1 and bigList2 now free for other use
because Apex is a garbage collected language where once an object reference is no longer reachable by the code the space occupied by the object can be re-used for other objects.
And also bear in mind that not all problems are suited to a simple Visualforce solution. For example, a more complicated Visualforce page can make multiple JavaScript requests mack to an Apex controller class and so break the problem down into multiple pieces each of which fits within the 6M Apex heap limit.
