CPU time limit jumps from 2000 to 14000 after a trigger ends

Question

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.

Answer 1

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.

Answer 2

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:

• That there is code in there where the performance degrades exponentially - see e.g. Fixing a common cause of System.LimitException: Apex CPU time limit exceeded; the good news is that such code can normally be fixed
• But if your trigger genuinely has a huge amount of work to do per record, then you will have to re-design to do that work asynchronously in batches

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.