2

Hi I am having trouble with the Apex CPU time limit. I've optimized my code as much as I know how to, but when my trigger finishes running it goes from 2000 to 14000.

Does anyone know what else is causing such a huge jump?

Here is my debug:

11:58:00:532 USER_DEBUG [268]|DEBUG|***getCpuTime()***2180
11:58:00:532 USER_DEBUG [269]|DEBUG|OpportunityTriggerHandler Before Update END
11:58:15:079 USER_DEBUG [735]|DEBUG|***getCpuTime()***14377 

Line 735 is inside another apex class that called an opportunity update which makes the trigger run. That debug is straight after my "update opps" call.

Context:

update OppsMap.values();
system.debug('***getCpuTime()***'+Limits.getCpuTime()); <-- Line Debug line 735

The code below seems to be what's causing the extra CPU time, as when it's commented out the CPU time goes from 14000 to 4000:

//Set opps to 'On Stop'
/*else if(emailTemplateName == 'DOC005')
{
opp.StageName = 'On Stop';
opp.On_Stop_Date__c = date.today();
opp.On_Stop_Reason__c = 'Dispute - No Payment';
}*/

This code is in my apex class, not the trigger its self. The trigger does have detections/conditions for the stagename changing however, but with the trigger commented out / disabled the CPU time is around 11000.

5

I suggest you add a similar debug line directly before the update (and at the start and end of your trigger) to confirm that that is where the CPU cycles are being used.

There are two possibilities for your trigger:

If your trigger is not large, post it in your question and you may get helpful feedback.

PS

The Executed Units tab in the Developer Console can sometimes be useful to identify code that is running way more times than you expect or that is taking way longer than you expect.

|improve this answer|||||
  • It's most certainly my trigger as I've ran my code without updating opportunitys and the cpu time ends at 1300. Every time the trigger finishes running it jumps to 13000-14000. It's a decent size trigger too aswell yeah(almost 300 lines). I've tried optimizing it with maps and minimal looping though. – Alexander Atkinsoon Sep 20 '19 at 12:11
  • @AlexanderAtkinsoon The looping to watch for is nested loops, as they generate exponentially rising cost. – Keith C Sep 20 '19 at 13:34
  • It seems to be from when i'm updating the stage value of my opportunity. I've isolated the code and a small 3 lines of changing some field values causes it to add on an extra 10,000 cpu time. With it commented out it only takes 4000. Do you know what could be the cause of this? – Alexander Atkinsoon Sep 20 '19 at 13:34
  • Triggers can go into an infinite loop i.e. your trigger changing a field causes your trigger to be called again ad infinitum. Add logging to make sure that isn't the case. Beyond that, I don't know. Well worth adding to the question though. – Keith C Sep 20 '19 at 13:38
  • Okay, i've updated my OP now. – Alexander Atkinsoon Sep 20 '19 at 14:16
4

If that's just your debug statements, that looks legit. Note that the time stamp moves from 11:58:00 to 11:58:15, fifteen seconds of time. You'll need to optimize your triggers more. This means profiling the code to see which methods are called the most, and how long they take. You should read about Working with Logs in the Developer Console for more information. Turn "Profiling" to "Finest" and set all other logging levels to "None". This will give you the most accurate representation of where the most time is being consumed.

One thing I'll mention, because it's often a primary source of wasted CPU time, is that debug statements always take time to execute, even if they are not logged. For example, doing this:

System.debug(LoggingLevel.NONE, Trigger.new);

Is an excellent way to waste hundreds or thousands of CPU cycles on something that will never be debugged (in other words, don't do this). Try commenting out all of your debug statements and see if that improves your performance. Use the Profiling logs to determine execution time.

Use checkpoints instead of debug statements to view the state of your code's memory. Note that you will need to increase the Apex log level to "INFO" to see these checkpoints evaluated, but they are much more reliable than debug statements, and checkpoints do not consume CPU time for normal users.

Once you've profiled your code, you'll have a better understanding of where your bottlenecks are, and you can begin proper optimization steps.

|improve this answer|||||
  • This extra cpu time seems to be caused from a few lines of code where i change some of the fields on opportunity. Its just 3 fields I change. With these 3 lines of code commented out the cpu time is back to 4000. Do you know what could cause this? – Alexander Atkinsoon Sep 20 '19 at 13:36
  • Are those specifics fields included in any workflows, process flows, subsequent triggers, etc.? – Chris Johnson Sep 20 '19 at 14:19
  • @AlexanderAtkinsoon It only takes a few lines to be horribly optimized. Without seeing your code, though, there's no way we can offer much beyond general advice. – sfdcfox Sep 20 '19 at 17:48

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.