Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

In order to debug we usually write chunks of data to the debug log using System.debug statements. Will writing too many debug logs affect visualforce page or Apex performance in any way?

share|improve this question
add comment

3 Answers 3

up vote 13 down vote accepted

I created the simplest page in the world, with a custom controller, that looked like this:

simple page

Generated by

<apex:page controller="spinspinspin" action="{!spin}">
    <h1>Congratulations</h1>
    This is your new Page
</apex:page>

And in the controller I simply had

public class spinspinspin {
    public void spin() {
        for(Integer i = 0; i < 100000; i++) {

        }
    }

}

I loaded this page up and inspected the source for the generation time, which is in a HTML comment at the bottom:

generated

Here we see the simple page took 80ms.

I loaded it 10 times and took an average of the load times, it was 78ms.

I then added System.debug to the for loop

for(Integer i = 0; i < 100000; i++) {
    System.debug(i);
}

and loaded the page 10 more times.

I averaged it out and the page now took 4140ms !!

I also then opened the developer console and checked, there were a bunch of 1.72Mb log files, so it was doing what one might expect, and the logging (allbeit 100,000 of them) was significantly slowing down the page load.

developer console

I then took the debug out of the loop (but left the empty loop as per the control) and added a single debug statement with a 3,500 character string in it. The average load for this page was 86ms indicating a single long debug statement does also slow the page.

(after this I was going to go on to a couple of other tests, but when I returned to the control state, I quickly re-tested my base level and they were up into the 100's of ms so I think either my DE on eu2 was being hammered, or I had simply worn a bit of it out temporarily! Therefore no future results would be fair ;) )

Update!!

Following other answers surrounding making the debug optional based on a boolean switch, I changed the controller to be this and ran the test again (I also re-ran my control a couple of times and the org was back on 75 - 85ms for standard page load)

private static final boolean logIt = false;

public void spin() {
    for(Integer i = 0; i < 100000; i++) {
        if(logIt) {
            System.debug(i);
        }
    }
}

The page load time was now an average (just 5 runs this time) of 112ms so the boolean flag does make a big difference. Putting that into a custom setting/label etc. and pumping it into the controller etc. might slow you down, but the concept of switchable logging has potential! (I was suspicious, so I changed the flag to true and loaded the page, low and behold, 4 seconds).

share|improve this answer
    
Thanks, @Simon. Yes, Great Answer. I had that doubt on the page performance but now i understood from your detailed explanation it really slows down the page performance. I have another question though. Would system.debug always write to debug log even if an user not configured in debug log setting? –  Baskaran S Jun 19 at 15:07
1  
Loading the log heavy page above without the developer console or logging enabled still took over 4 seconds, so even though I was not accessing the logs they appear to be being executed. That is a good question though! I'd be interested to hear a little more about the debug architecture. Maybe pop that in another question and see if another expert pops up!! –  Simon Lawrence Jun 19 at 15:11
4  
You're always bring logged. With logging turned off, the call still happens. In short, any line of code you execute has a time penalty. Many best practice lists, including security review checklists, advise removing all debug statements from production code. –  sfdcfox Jun 19 at 15:22
1  
With the Boolean flag, you skip calling the debug line, so far less time penalty. A full blown solution might be to write a custom logger that checks a custom setting and only calls system.debug if a value is set. –  sfdcfox Jun 19 at 16:14
2  
yes, obviously evaluating an IF statement is a lot lighter than executing a System library call and persisting data etc.etc. you could have different "levels" of flag and wrap different debug in them (thus emulating for example the functionality of log4j). –  Simon Lawrence Jun 19 at 16:36
show 3 more comments

Building on top of Simon's answer, if a page loads on average in 78ms with no debug statements but loads on average at 4140ms with 100,000 debug statements, we could determine:

  • By adding the debug statements, our load time increased 4062ms.
  • On average, each debug statement added .04062ms to load times.

Now, these are obviously the most simple debug statements you would ever use. If they were longer, it would be safe to say the time it takes to log these debug statements may increase. For the sake of argument, let's say a debug statement averages 5x as long as the simplest debug statement. In that scenario, we are looking at .2031ms. Let's go a step further and say it is 10x the simplest debug statement, even then we are only looking at .4062ms.

At 10x the simplest debug statement for the average debug statement, we can log 2461 statements and still only effect the page by slightly under a second (999.65ms). While it does effect performance, I think it is safe to use them in most circumstances, given that you most likely won't be running thousands of debug statements. Be smart and keep them out of loops, etc and you should be fine to debug the information you need with a minimal effect on performance.


To be clear, this isn't to say you should put thousands of debug statements in your code. As sfdcfox noted in a comment on Simon's answer, on performance critical pages being able to shave a few milliseconds add up to increase performance.

All I am saying by this is that if you have a troublesome page that you need to put a few debug statements in, it isn't the end of the world. If a page takes 1 second to load without debug statements, a few debug statements won't add more than a few milliseconds. Will a user really notice the difference between a 1 second page load and a 1.05 second page load? I would argue they wouldn't.

share|improve this answer
1  
Yes, this is a good point! My answer was intended mearly to prove the fact, and not to accidentally scare-monger!! A few hundred (or thousand) debugs are not going to hurt your performance, but as they do have an impact avoid sticking them in too many loops. I would be surprised if even the most attentive developer could make a tangible difference to page load times (compared to other massively affecting factors like code and query efficiency, and/or fluctuating server/internet response times). –  Simon Lawrence Jun 19 at 15:22
    
Thanks a lot @Jesse. Great notes to read and keep it in my library. –  Baskaran S Jun 19 at 15:44
    
Debug statements still don't belong in production code, so one should keep them to a minimum. Your primary reliance should be on test methods to validate logic. I often find asserts are more useful for debugging because when a failure occurs, users get meaningful errors you can use, instead of digging through logs. Of course, asserts should be kept to a minimum as well. Checkpoints are incredibly useful for debugging as well. You use them to get the entire state of the system, and they can be turned on and off without code. –  sfdcfox Jun 19 at 18:26
add comment

What you are really asking is,

How can I have debug statements in my code for future debugging without affecting current performance excessively?

I suggest structuring your debug calls like this:

If (DebugOn)
    System.debug('your message here.');

where DebugOn is a static class variable. For extra convenience, DebugOn could load its value from a Custom Label. That way, you can turn logging on without changing your code. As suggested in other answers, keeping logging out of loops will help avoid performance issues.

share|improve this answer
1  
While this check will help make the performance impact extremely minimal, it will effect performance because that if check will have to run at all of those messages. It will be extremely minimal and it is a good idea, but you can't say it won't effect performance at all. –  Jesse Altman Jun 19 at 15:46
2  
Wouldn't the IF statement itself take up some processing overhead? If you tried Simons test and put this in a loop 100,000 times I wonder whether you'd see performance degradation –  Doug B Jun 19 at 15:47
1  
I was just doing that! –  Simon Lawrence Jun 19 at 15:49
2  
Please see the update to my answer. The result is astounding! –  Simon Lawrence Jun 19 at 15:56
    
Very interesting results! Thanks for doing the tests. –  Jagular Jun 19 at 16:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.