6

You'll have to forgive me if I failed to RTFM as to why I'm seeing this, but I was under the assumption as of Winter '14 that Apex execution contexts are no longer measured in code statements, but in CPU time. Looking at my debug logs in my companies' and my personal developer instances, I still see a measure for code statements and a zero value for CPU time:

09:55:22.849|LIMIT_USAGE_FOR_NS|(default)|
  Number of SOQL queries: 3 out of 100
  Number of query rows: 436 out of 50000
  Number of SOSL queries: 0 out of 20
  Number of DML statements: 0 out of 150
  Number of DML rows: 0 out of 10000
  Number of code statements: 1043 out of 200000
  Maximum CPU time: 0 out of 10000
  Maximum heap size: 0 out of 6000000
  Number of callouts: 0 out of 10
  Number of Email Invocations: 1 out of 10
  Number of fields describes: 0 out of 100
  Number of record type describes: 0 out of 100
  Number of child relationships describes: 0 out of 100
  Number of picklist describes: 0 out of 100
  Number of future calls: 0 out of 10

Any ideas? Is there some setting that needs to be enabled?

  • It used to be that things like this would only change once you update your API version to the corresponding release. What API version are you using? – Daniel Ballinger Dec 19 '13 at 19:08
  • 2
    Crazy idea, write an infinite loop as see what limit you hit. – Daniel Ballinger Dec 19 '13 at 19:09
7

After a quick test I think you just need to work harder to get the CPU time to register. The code statements limit doesn't seem to be enforced.

Testing code. Try increasing the loops count.

long counter = 0;
long loops = 5299999;
for(long i = 0; i < loops; i++) {
    counter++;
}
System.assertEquals(loops, counter);
System.debug(counter);

With loops 5299999 against a development edition org.

Number of SOQL queries: 0 out of 100
Number of query rows: 0 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 0 out of 150
Number of DML rows: 0 out of 10000
Number of code statements: 5300004 out of 200000 * CLOSE TO LIMIT
Maximum CPU time: 8904 out of 10000 * CLOSE TO LIMIT
Maximum heap size: 1091 out of 6000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

With loops = 7299999 against a development edition org.

Number of SOQL queries: 0 out of 100
Number of query rows: 0 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 0 out of 150
Number of DML rows: 0 out of 10000
Number of code statements: 7300004 out of 200000 * CLOSE TO LIMIT
Maximum CPU time: 11990 out of 10000 * CLOSE TO LIMIT
Maximum heap size: 1091 out of 6000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

With loops = 7299999 against a Enterprise edition production org.

Number of SOQL queries: 0 out of 100
Number of query rows: 0 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 0 out of 150
Number of DML rows: 0 out of 10000
Number of code statements: 7300004 out of 200000 * CLOSE TO LIMIT
Maximum CPU time: 14415 out of 10000 * CLOSE TO LIMIT
Maximum heap size: 1091 out of 6000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

With loops = 17299999 against a Enterprise edition production org.

System.LimitException: Apex CPU time limit exceeded

Number of SOQL queries: 0 out of 100
Number of query rows: 0 out of 50000
Number of SOSL queries: 0 out of 20
Number of DML statements: 0 out of 150
Number of DML rows: 0 out of 10000
Number of code statements: 9177462 out of 200000 * CLOSE TO LIMIT
Maximum CPU time: 15115 out of 10000 * CLOSE TO LIMIT
Maximum heap size: 1091 out of 6000000
Number of callouts: 0 out of 10
Number of Email Invocations: 0 out of 10
Number of fields describes: 0 out of 100
Number of record type describes: 0 out of 100
Number of child relationships describes: 0 out of 100
Number of picklist describes: 0 out of 100
Number of future calls: 0 out of 10

So, from the above tests, I'd conclude that the code statements limit isn't enforced anymore. The CPU time will cause a LimitException, but the actual Maximum CPU time limit is a bit fuzzy. It might be that Salesforce have stretched the limit to avoid possible issues but this isn't reflected in the reported Maximum CPU time. Or it might be that they can't actually instantly enforce the CPU limit when you hit it and will only detect you have passed it at some point in the future.

| improve this answer | |
  • The API version is 29.0. Interesting. So even I consumed 0.5% of the code statements, CPU time did not even register. I had just assumed that would correlate to somewhat equivalent CPU time of roughly 50ms. I'll run some of my more code intensive class test under 29.0 and see if I can get some CPU time values. Thanks – kbentsen Dec 19 '13 at 19:53
  • 1
    I'm guessing that they have some form of task scheduler that periodically checks in on the thread to see if it is still going, what the current CPU time is, and if it needs to be killed. Because it will sit outside the current thread/process quick jobs might not even register and there will some some variance in the checks. – Daniel Ballinger Dec 19 '13 at 19:58
  • 5
    CPU time is a flexible limit. It may be exceeded around 50% over the documented limit as resources allow. You shouldn't expect to always get that much time, but you will always get at least 10,000 ms. – sfdcfox Dec 19 '13 at 20:23
  • 2
    Also, most of the resource-based limits are fuzzy. I've created a script that consumed about 50mb of memory without triggering a heap failure-- it built a string 1mb long, repeated it 50 times, then quickly dumped it before the system could register what happened. I think the system runs the code in "slices" and checks the governor limits every few (dozen?) ticks of execution or so. It's hard to nail down exactly how long you can exceed a limit. – sfdcfox Dec 19 '13 at 20:25

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.