CODEWITHSUNDEEP
javaperformance
M.J.
M.J.

Reputation: 16646

which toString() method can be used performance wise?

I am working on one project for performance enhancement. I had one doubt, while we are during a process, we tend to trace the current state of the DTO and entity used. So, for this we have included toString() method in all POJOs for the same. I have now implemented toString() in three different ways which are following :-

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 anyone please help me to find out which one is best and should be used for enhancing performance.

Upvotes: 6

Views: 3817

Answers (4)

Raj Kaimal
Raj Kaimal

Reputation: 8304

This is more readable IMO

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

Upvotes: 2

cletus
cletus

Reputation: 625057

Use the first one. I'll explain why.

The naive view is to use the last one. There's no reason to use the second one. A StringBuffer is the same as a StringBuilder except it has a performance hit from synchronized locks. But don't put it on one line. This is much 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();
}

That being said, you have to be careful about this kind of micro-optimization. Why? Because the compiler will often do this for you. So write whatever is most readable and let the compiler optimize it.

So the major lesson here is: don't micro-optimize.

Ultimately though, it probably doesn't matter which one of 1 or 3 you use. toString() methods don't tend to be used a huge amount in an application. More commonly they're used in error messages, which are hopefully infrequent.

Upvotes: 3

polygenelubricants
polygenelubricants

Reputation: 383746

The one with the + is fine in this case. It's more readable, and it's just as performant compared to the StringBuilder/StringBuffer version, since it' doesn't happen inside a loop.

If you are building a String inside a loop, then more often than not you should use StringBuilder. Only use StringBuffer if you need its synchronized feature, which doesn't happen very often.

Simplistically speaking (not true always, but is a good rule of thumb), unless you're doing a += with a String, you don't really need a StringBuilder/StringBuffer.

Related questions

A String.format option

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

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

I find that this is the most readable and maintainable version.

Is this faster? Maybe yes, maybe not. It usually doesn't matter for common use case scenarios for something like toString(). Strive for readability, only optimize if profiling says it's necessary.

API links

On Class Literals

I've corrected a syntax error in the original code from this.class (which doesn't compile) to this.getClass().

See also

Related questions

Upvotes: 13

Bozho
Bozho

Reputation: 597076

Use the 1st one, because it's more readable.

But otherwise, it doesn't matter.

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

  • the StringBuffer will be slower, due to its methods being synchronized, but since escape analysis (more specifically - synchronization elision) might used by the compiler (in newer versions), it will automatically remove the synchronized keyword. (See JDK 6u14 release notes to learn about escape analysis)

Upvotes: 9

Related Questions