Archive for July, 2012

Java Optimization Tips

July 27, 2012

When writing Java code it can be easy to make simple mistakes that seem harmless on the surface but, as our applications grow larger, they can show themselves to be slow, resource intensive processes that could use a tune-up. Luckily there are some easy ways to optimize your Java code that you can begin using today. Here, we will introduce you to five of them.

1. Avoid unnecessary casting

Casting, for the new developer, is a way of converting between reference data types. Most casting is done to allow a more generic form of programming where your code will be able to work with all types of objects and classes that are descended from some type of base class.

However, new programmers do not always write these casting statements correctly and are creating a situation where they are improperly casting and creating more overhead for their application in the VM than necessary. An example:

class MyCastingClass {
    public Object myMethod() {
        String myString = "Some data";
        Object myObj = (Object) myString;
        return myObj;
    }
}

Ok, let’s examine the statement Object myObj = (Object) myString; which is violating the unnecessary casting rule. There would be no reason to explicitly cast the string to an Object type since the string class already inherits from Object. Casting also bypasses the safety checks of the Java compiler and can end up causing errors at execution. The proper way to write this code would be:

class MyCastingClass {
    public Object myMethod() {
        return "Some data";
    }
}

Clean, easy to read and maintainable while preserving the rules of the compiler and creating less memory overhead. A very simple fix.

2. Eliminating Common Sub Expressions

A common mistake is the use of the same common sub-expression repeatedly in your code, yet you continue to type it out for each calculation. An Example:

int someNumber = (someValue * number1 / number2) + otherValue;
int someNumber2 = (someValue * number1 / number2) + otherValue2;

You may not realize it but you do this all the time. Performing a calculation that has a portion repeated over and over for each calculation. Because part of the calculation changes each time, you didn’t think to loop it and save yourself some trouble. Instead you are being redundant and slowing down the speed of your calculations. Here is a fix:

final int constantCalculation = (someValue * number1 / number2);
int someNumber = (constantCalculation) + otherValue;
int someNumber2 = (constantCalculation) + otherValue2;

Bingo! By placing the repeated portion of the sub-expression into a constant we can reuse it for multiple calculations without being redundant. A deceptively simple optimization.

3. Use StringBuffer (or StringBuilder) instead of String for non-constant strings.

Since strings are immutable objects and cannot change it creates a lot of overhead when you perform actions with string objects that the compiler must transform in order to interpret. Operations that appear to change string objects are actually creating new ones behind the scenes in order to perform your operation. The overhead on this becomes higher when you use String instead of StringBuffer (or StringBuilder). For Example:

class MyStringClass {
    public void myMethod() {
        String myString = "Some data";
        for (int i = 0; i < 20; i++) {
            myString += getMoreChars();
        }
    }
}  

This is the reason that the StringBuffer class exists, to provide assistance when concatenating strings since a new object would need to be created to transform the string. The new object the compiler will create is of type StringBuffer. A new string object would then be created to copy the finished string at the end of the transformation, thus creating two new objects to perform this simple step.

The difference between StringBuffer and StringBuilder is that the former is thread-safe, which is great in some cases, and an overhead in others. All StringBuffer‘s methods are synchronized. StringBuilder isn’t thread-safe and its methods aren’t synchronized, which is much more performant when you just need to use it as a local variable.

The solution would be to cut out the StringBuffer middle-man and make our own StringBuffer object so the compiler doesn’t have to:

class MyCastingClass {
    public Object myMethod() {
        String myString = "Some data";
        StringBuffer myBuffer = new StringBuffer();
        for (int i = 0; i < 20; i++) {
            myBuffer.append(getMoreChars());
        }
        myString = myBuffer.toString();
    }
}

Voila! By creating our own StringBuffer class the compiler no longer has to create one for us to do the transformation. This means there is now only one new string object being created during this process when we call the toString() method of the buffer to transfer that data to myString.

4. Use Short Circuit Boolean Operators

When making logical checks or tests in your code, the use of short-circuit evaluation will almost always speed up the time it takes to make the evaluation because the compiler does not have to check the second condition. When two expressions are joined by an OR (||) as long as the first one is true the compiler will not check the second condition, it will assume the whole statement to be true. This also works with AND (&&) where the compiler will evaluate the first state and if false, will evaluate the whole statement to false. However, the logical OR (|) does not use the short circuit evaluation.

Using || saves the compiler time by not having to check both conditions because it wouldn’t change the outcome of the statement. Here is an example of what usually happens:

class MyShortCircuitClass {
    public void myMethod() {
        if (someValue.equals("true") | someValue.equals("false")) {
            System.out.println("valid boolean");
        }
    }
}

What ends up happening in the above example is that the compiler has to check both conditions and evaluate a true or false for each even through the OR logic would have made it true if the first condition evaluated to true. Here is a better way to write these kinds of statements:

class MyCastingClass {
    public void myMethod() {
        if ("true".equals(someValue) || "false".equals(someValue)) {
            System.out.println("valid boolean");
        }
    }
}

By using short-circuit evaluation you will speed up the time it takes for the compiler to make boolean logical decisions and thus the overall processing time of your application.

Here’s a table describing four of Java’s boolean operators:

Meaning Short circuit?
&& and yes
& and no
|| or yes
| or no

The && and || operators are short circuit operators. A short circuit operator is one that doesn’t evaluate all of its operands.

5. Use length() instead of equals() to find the length of a string

It seems to be common practice among developers that when testing for an empty string to use the equals() method, like so:

class MyStringClass {
    public boolean myTestMethod() {
        return myString.equals("");
    }
}

The problem here is the sheer overkill taking place by using equals() due to the higher overhead. The issue comes from the implementation of equals() which is designed to test if two objects reference back to the same object class. The alternative, length() (or isEmpty()), just tests to see if the references point to the same underlying object type. This is a much more efficient way if you are just testing for an empty string. You don’t care about object types or if they reference back to the same class, so quit using a sledgehammer to pound the nail. Here is how you should be testing for empty strings:

class MyCastingClass {
    public void myMethod() {
        public boolean myTestMethod() {
            // which really does myString.length() == 0 behind the schenes
            return myString.isEmpty();
        }
    }
}

Using length() provides a much more efficient method for testing for empty strings that does not require object reference overhead from the compiler.

Remember that code optimization doesn’t require fancy tricks and unreadable code. These are often simple changes that you can start making today that will speed up your processing time and make your code better. A lot of optimization is getting into the underlying processing of the compiler and understanding what is taking place in the code that you write. By learning these tips now you can begin to implement them into your solutions every time, thus making you a better developer in the process.

Courtsey : 5 Easy Java Optimization Tips/

Advertisements

The Ten Commandments of Egoless Programming

July 11, 2012

The Ten Commandments of Egoless Programming:

  1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry. We can, and should, learn, laugh, and move on.

  2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

  3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

  4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

  5. Treat people who know less than you with respect, deference, and patience. Non-technical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

  6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.

  7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

  8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.

  9. Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.

  10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

Courtsey : http://blog.stephenwyattbush.com/2012/04/07/dad-and-the-ten-commandments-of-egoless-programming


%d bloggers like this: