IsInfoEnable () and reviewisinfoenable of code review

IsInfoEnable () and reviewisinfoenable of code review

Last week, I had nothing to do with scanning the original code of the system and suddenly found such a piece of code:

if(log.isInfoEnable()){    log.info("ID"+userID+"pwd"+userPwd);}

Because the previously written log classes are internal log classes of the company, they are not used much for log4j. At that time, I thought it was strange to read this code. I understood the code. log itself can determine whether to print the code based on the print permission. Why should I add such a judgment? Later I checked and found that it was due to performance considerations.

If you write such a paragraph directly

    log.info("ID"+userID+"pwd"+userPwd);

When the print level is "info", the system will not intelligently skip this sentence, but will enter the content of this sentence. The first thing before going in is the calculation parameter.
Then the string will be concatenated here.

In general, the lower the log printing level, the more detailed the printed content (the more debugging and tracking code). At this time, there will be more and more String concatenation or parameter calculation tasks, it will consume more performance. If

If we set the current printing level to be very high, such as the ERROR level, logs of the debug and info levels will not be printed, but due to the many print statements of debug and info, assembly parameters consume a lot of performance, so we can judge whether the statement can be printed out first, although at first glance, we will feel that this is the case, in fact, the more logs debug and info, the more you can save unnecessary performance overhead.

Many people on the Internet say that encapsulation cannot be used for the ease of code, because when calling the encapsulated method, the parameter calculation has actually started, but it looks ridiculous, as shown below:

Public void info (String msg) // The current msg is actually a concatenated String {if (log. isInfoEnable () {log.info ("ID" + userID + "pwd" + userPwd );}}

 

Reflection after Summarization

1: Many people think that if it is not encapsulated, it will damage the Code's ease of authorization. It is difficult to see. If it is encapsulated, it will have a reverse effect, so we should not save on this performance at all, putting time and energy on database connection queries, data loading and sorting, and so on, is more performance-consuming. In fact, I also agree. I think performance optimization should be performed on a layer-by-layer basis, there is no need to hold down all the details from the very beginning. Of course, it is good to abide by a certain coding system. However, if we start from all the details at the beginning, it will affect other important optimization points.

2: For this writing method, I personally thought that the following writing method can not only ensure the readability of the code, but also reflect the performance advantages of this judgment. However, there will be an additional performance overhead for creating arrays.

1 public void info (String... args) // use variable parameter 2 {3 if (log. isInfoEnabled () 4 {5 StringBuilder sb = new StringBuilder (); 6 for (int I = 0; I <args. length; I ++) 7 {8 sb. append (args [I]); 9} 10 log.info (sb. toString (); 11} 12} 13}