4

I just tried to run this little snippet in 'Execute Anonymous' on our org:

list<Case> caseList = [SELECT ID, Last_Case_Comment_By__c, Last_Case_Comment_Date__c, (SELECT ID, CreatedDate, CreatedBy.Name FROM CaseComments ORDER BY CreatedDate DESC) 
                       FROM Case 
                       WHERE ID IN (SELECT ParentID FROM CaseComment) 
                       AND AccountID = '0018000000mHBLJ' 
                       AND Last_Case_Comment_By__c = NULL 
                       AND Last_Case_Comment_Date__c = NULL];

for(case c : caseList){
    c.Last_Case_Comment_By__c = c.CaseComments[0].CreatedBy.Name;
    c.Last_Case_Comment_Date__c = c.CaseComments[0].CreatedDate;
}

update caseList;

As you can see, it's pretty straightforward: I query all Cases that have at least one case comment belonging to a given account, then update a couple fields on the Case using data from the most recent comment.

caseList.size() = 1463

Number of query rows = 8737

Neither of these numbers seem particularly high.. does anyone have any insight into why this would hit the Apex CPU Time Limit error?

I threw a LIMIT 500 into the SOQL and it ran, so clearly processing the query is what's taking the time... but any ideas on what the big CPU consumer is in that Query?

  • 2
    I would bet the culprit is your CaseComment inner join. Perhaps you could add a filter on that query to just search for comments where CreatedDate = THIS_YEAR? – Adrian Larson Aug 22 '16 at 21:25
  • 3
    You could also add LIMIT 1 to your CaseComments subquery. You don't need any of the older comments. – Adrian Larson Aug 22 '16 at 22:01
  • 3
    WHERE <field> = null is generally a performance killer as well. I don't know if it'd work on this query, but looking at the output of the query plan tool through the developer console might give you some additional insight. Leading operation type of Tablescan is bad. – Derek F Aug 22 '16 at 22:33
  • 2
    Can you post the debug log? My understanding is that DML and SOQL do not count towards the CPU limit. So while the query might be slow, that shouldn't matter for the CPU time. – Daniel Ballinger Aug 23 '16 at 20:46
  • 1
    @DanielBallinger That is interesting.. excluding SOQL and DML all I've got in that code snippet is a loop through Cases with two variable assignments.. maybe there are unrelated Case triggers firing and taking up CPU time? Unfortunately I can't post a log: already updated all our cases so I no longer get the error when running the code snippet... – smohyee Aug 24 '16 at 16:03
3

My understanding is that DML and SOQL do not count towards the CPU limit. So while the query might be slow, as long as it completes it shouldn't matter for the CPU time.

The loop itself seems to be fairly tight and doesn't include anything that would obviously blow out the CPU time.

As you commented, I suspect the problem would be in any Apex triggers that fire before or after a Case is updated. A full debug log would be helpful in showing where the CPU time is going. If you open the debug log in the developer console you can do Debug > Perspective Manager > Analysis. There will be a graph showing where the CPU time went on the Timeline tab.

enter image description here

You could also scatter your anonymous apex code with Limit.getCpuTime():

System.debug(LoggingLevel.Info, 'CPU: ' + Limits.getCpuTime() + '/' + Limits.getLimitCpuTime());
  • Daniel I ran a similar code snippet to test, and you were correct - the CPU time limit was actually eaten up by unrelated Case Triggers. I also had no idea bout the execution analysis options either, thanks for the tip! – smohyee Sep 7 '16 at 19:32

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.