5

enter image description here

I am experiencing an Apex Cpu Limit and as per checking am I correct that it is in the opportunitytrigger? shoudl I optimize it more?

   if(Trigger.isBefore){
    if(Trigger.isInsert){
        OpportunityTriggerHandler.setOppProposalNumber(trigger.new);
        OpportunityTriggerHandler.setOppProjectEndDateBeforeInsert(trigger.new); 
        OpportunityTriggerHandler.updateOpportunityCodeOnInsert(trigger.new); 
        if (OpportunityTriggerHandler.donotRunTBPforSomeTestClasses) 
            OpportunityTriggerHandler.TimeBasedPipelineProcessingBeforeInsert(trigger.new);           
        OpportunityTriggerHandler.leadConversionBeforeInsert(trigger.new);
    }
    if(Trigger.isUpdate){

        for (integer i = 0; i < trigger.new.size(); i++) {
           if (trigger.new[i].Pricebook2id !=  trigger.old[i].Pricebook2id)
               trigger.new[i].Expected_Commitment_Date_Check__c = TRUE;
        }

        if(tcsetting.editedFromAccount__c == false){
            OpportunityTriggerHandler.setOppProjectEndDateBeforeUpdate(trigger.New, trigger.OldMap); 
            OpportunityTriggerHandler.updateOpportunityCodeOnFieldChange(trigger.NewMap, trigger.OldMap); 
            if(OpportunityTriggerHandler.firstRun && OpportunityTriggerHandler.donotRunTBPforSomeTestClasses){
                OpportunityTriggerHandler.TimeBasedPipelineProcessingBeforeUpdate(Trigger.New, Trigger.OldMap);
            }       
        }         
        OpportunityTriggerHandler.leadConversionBeforeUpdate(trigger.new);
    }
    if (Trigger.isDelete){
        OpportunityTriggerHandler.delOppLightRecord(trigger.old);
        OpportunityTriggerHandler.UpdateAccountPlanTotalDF(trigger.old);
    }
}
1
  • I checked that what runs most is the workflow next is a trigger third is validation, but why is it that it doesn't show on execution overview the workflow, actually i am having problem in data loading
    – Torrific
    Commented Aug 3, 2017 at 19:55

3 Answers 3

5

From your screenshot it would appear that the majority of the Apex CPU time has been spent on validation. It is taking up 63% of the transaction time. This would be the most productive place to look at improving performance.

If you could provide a link to the complete debug log it might be possible to isolate the problem further.

2
  • Does validation rules contribute to Apex CPU time limit? Say we have an Object and that object is being data loaded by data load, and that object has say 100 validation rules, will these validation rules contribute to CPU time limit? Commented Aug 1, 2018 at 6:13
  • @RahulJain Certainly validation rules that are based on formula count towards the Apex CPU limit Additional Ref. In my head that is all validation rules. Or at least what I think of as validation rules. Commented Aug 1, 2018 at 9:17
5

According to what your Execution Overview is showing, 63% of your time is being spent in Validation while only 23% of your time is being spent running Apex Code. Your code calls other handlers that you don't show the code for.

Regardless, it's your validation rules that are consuming the largest chunk of time that's causing your time out. I recommend you look at those first to see if any can either be rewritten, refactored, or eliminated completely to reduce the amount of CPU time validation is consuming in the transaction.

1

Your for loop doesn't seem to be efficient. It's a very common mistake to think you are writing a faster one, but you are not.

for (integer i = 0; i < trigger.new.size(); i++) {

Should be

for (integer i = 0, j = trigger.new.size(); i < j; i++) {

With first one, at each iteration collection size will be computed. It's essentially same as doing for(opportunity i: trigger.new). With second one, collection size will be computed once - which is riskier if you plan to remove items from your collection :)

Also, the analysis view is not always reliable. I've tried once to add a ridiculous amount of validations and workflows, just to find that in reality they do not amount much to. Perhaps try to but some system.debug() outputs from Limits class, so you can track your transactions more precisely.

Finally, having handlers for operation is great, but as they probably have an for loop in each one, CPU time is very quickly wasted. You'll have to consolidate all your loops into one method. You can also consider if some of the logic can be detached from the transaction into a asynchronous future/queueable interface. Generally only operations that can cause validation errors should be synchronous, but of course business can protest and want some information to be available immediately.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .