Which toString () method can I use in terms of performance?

Question

I am working on one project to increase productivity. I had one doubt, while we are in the process, we tend to keep track of the current state of the DTO and the object being used. So, for this, we have included the toString () method in all POJOs for this. Now I implemented toString () in three different ways: -

public String toString() { return "POJO :" + this.class.getName() + " RollNo :" + this.rollNo + " Name :" + this.name; } public String toString() { StringBuffer buff = new StringBuffer("POJO :").append(this.class.getName()).append(" RollNo :").append(this.rollNo).append(" Name :").append(this.name); return buff.toString(); } public String toString() { StringBuilder builder = new StringBuilder("POJO :").append(this.class.getName()).append(" RollNo :").append(this.rollNo).append(" Name :").append(this.name); return builder .toString(); } 

Can someone help me find out which one is better and should be used to improve performance.

Answer 1

In this case, excellent with the + tag. This is more readable, and it is the same as execution compared to the version of StringBuilder/StringBuffer , since it does not happen inside the loop.

If you are building a String inside a loop, then most often you should use StringBuilder . Use StringBuffer only if you need its synchronized function, which does not happen very often.

Simplified (not always, but this is a good rule), if you do not do += with String , you really don't need StringBuilder/StringBuffer .

Related Questions

• StringBuilder vs String Concatenation in toString () in Java
• String, StringBuffer, and StringBuilder
• StringBuilder and StringBuffer in Java

---

A String.format option

One option that is often not considered is to use String.format . It will look something like this:

 return String.format("POJO : %s RollNo %s : Name : %s", this.getClass().getName(), this.rollNo, this.name ); 

I believe that this is the most readable and supported version.

It's faster? Maybe yes maybe no. Usually this does not matter for sharing scripts for something like toString() . Strive for readability, only optimize if profiling says it is necessary.

API Links

• java.util.Formatter syntax

---

In the literal class

I fixed a syntax error in the source code from this.class (which does not compile) to this.getClass() .

see also

• JLS 15.8.2 Class Literals

Related Questions

• What is a class literal in Java?

Answer 2

Use the first because it is more readable.

But otherwise it does not matter.

• Using StringBuilder and + in this case is equivalent, because the compiler translates the overloaded + operator to StringBuilder .

• StringBuffer will be slower due to its synchronized methods, but since the escape analysis (more precisely, synix elision), which can be used by the compiler (in new versions), it will automatically delete the synchronized . (See JDK 6u14 Release Notes for an evacuation analysis)

Answer 3

Use the first one. I will explain why.

The naive idea is to use the latter. There is no reason to use the second. A StringBuffer is the same as StringBuilder , except that it has a performance hit from synchronized locks. But do not put it on one line. This is more readable:

 public String toString() { StringBuilder out = new StringBuilder(("POJO :"); out.append(this.getClass().getName()); out.append(" RollNo :"); out.append(this.rollNo); out.append(" Name :"); out.append(this.name); return out.toString(); } 

Speaking of which, you should be careful in this micro-optimization. What for? Because the compiler will often do this for you. So write what is most readable and let the compiler optimize it.

So, the main lesson: do not optimize .

Ultimately, although it probably doesn't matter which of 1 or 3 you use. toString() methods usually do not use a huge amount in the application. Most often they are used in error messages, which I hope are infrequent.

Answer 4

This is a more readable IMO

 public String toString() { return String.Format("POJO : {0} RollNo : {1} Name : {2}", this.getClass().getName(), this.rollNo, this.name); }