I am getting this error: 'Error:System.LimitException: Apex CPU time limit exceeded' for this simple trigger. The trigger is working just fine. Can anyone tell me if I am doing something wrong in the script below. I will appreciate any help!

 trigger UpdateNRProducts on Account (after update) {

   Set<NRProducts__c> parents = new Set<NRProducts__c>();

   for (NRProducts__c  a : [SELECT Id FROM NRProducts__c WHERE Account__c IN :Trigger.new]){

    parents.add(new NRProducts__c(Id = a.id )); 


    if(!parents.isEmpty()) update new List<NRProducts__c>(parents);


or This trigger which is in the NRProducts Object

   trigger buyerlookupTriggerNRProducts on NRProducts__c (before insert,before update) {

  Map<id,Account> map1= new Map<id,Account>();
  for(NRProducts__c rod : Trigger.new){
  map1 = new Map<ID,Account>([select id, Owner.id, Specialist__c, Brand_Manager__c  from Account where Id IN : map1.keySet()]);

  for(NRProducts__c rod : Trigger.new)
  if(map1.get(rod.Account__c) != null){

            rod.Buyer_Lookup__c = map1.get(rod.Account__c).Owner.id;
            rod.Specialist_Lookup__c = map1.get(rod.Account__c).Specialist__c;
            rod.Brand_Manager__c = map1.get(rod.Account__c).Brand_Manager__c;

  • and did you by any chance look at the debug log to gain any insight? Is it happening for a specific Account, a batch of Accounts? How many NRProducts__c are returned and what, if anything happens when an NRProduct is updated?
    – cropredy
    Aug 15, 2014 at 22:35
  • crop1645, usually and Account has around 200 NRProducts, so I don't think that's an issue. There is an API running on NRProducts__c Object all day long. Do you see anything wrong with code? if not, do you think the API is interfering?
    – Carlos
    Aug 15, 2014 at 22:44

1 Answer 1


Your problem isn't here, but somewhere else. You'll need to set profiling to the highest level ("FINEST") and see which functions consume the most time in the heap/debug logs.

"API's running all day long" wouldn't cause this error either, as CPU limits are per-transaction. There's just some function that's eating up enormous amounts of CPU time. Check for any triggers on NRProducts__c, see if there's any DML operations that would cascade further updates, etc.

By the way, you can write your entire trigger like this:

trigger updateNRProducts on Account (after update) {
    update [SELECT Id FROM NRProducts__c WHERE Account__c IN :Trigger.new];

This removes the need for the loop (which uses CPU time), although that loop shouldn't be anything more than a few milliseconds. Assuming you have similarly structured code elsewhere, it could just be too much inefficient code eating away at the total CPU time available.

Personally, I'd guess that the NRProducts__c triggers are using nested loops instead of maps, or somewhere else down the line has that problem.


Loops are very slow. Extremely.

Consider the following code:

Long time1 = DateTime.now().getTime();
Account[] records = new Account[0];
Account[] temp = [SELECT Id FROM Account LIMIT 1000];
Long time2 = DateTime.now().getTime();
System.debug(LoggingLevel.ERROR, DateTime.now().getTime());
for(Account record:temp)
    records.add(new Account(Id=record.Id));
Long time3 = DateTime.now().getTime();
System.debug(LoggingLevel.ERROR, 'Query Time: '+(time2-time1)+'ms');
System.debug(LoggingLevel.ERROR, 'Loop Time: '+(time3-time2)+'ms');

1,000 records in my org outputs the following:

17:04:09:691 USER_DEBUG [9]|ERROR|Query Time: 20ms
17:04:09:691 USER_DEBUG [10]|ERROR|Loop Time: 5638ms

I'm not sure if it's memory allocation or a slow iterator, but there's definitely some odd going on here. Save your CPU time and just update the list directly. Avoid memory-hogging loops.

  • I will try that right now..
    – Carlos
    Aug 15, 2014 at 23:07
  • sfdcfox, i am new in SF, could you please show me an example of nested loops. I don't know how to differentiate one. I truly appreciate your help.
    – Carlos
    Aug 15, 2014 at 23:09
  • 1
    A nested loop is a loop inside a loop, like for(...) { for(...) { ... } }. This has a very poor performance (e.g. 200 records by 200 records is 40,000 executions of code).
    – sfdcfox
    Aug 15, 2014 at 23:10
  • 1
    For anyone else who comes across this as of 11 Nov 2014, for 1000 records I get a query time of 18ms, iterator looping to create new SObjects 88ms, iterator looping to create new strings 44ms, iterator looping to increment an integer 20ms, and a pure loop counter loop to increment an integer 10ms. So the iterators are OK, though it remains an eye-opener that it is quicker to query the data than build a copy through a loop. (We are chasing a performance problem, hence the double check of this.)
    – Keith C
    Nov 11, 2014 at 18:34
  • 1
    The answer above is correct, and the speed of the database compared to local code is remarkable. I wanted to share a bit more, though. To piggyback off of @Keith-C 's comment, the important thing here is that the database query doesn't really scale with the number of records, whereas the loop does. If you expect to loop and create only 5 objects, the loop will be faster. If you are creating 1,000 or 1,000,000, the database will take roughly the same amount of time. The loop time scales with the number of records. (I tested this in 2019.) Nov 26, 2019 at 18:56

You must log in to answer this question.

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