I have found the following simple way of making small improvements to performance for projects in the past.
- Use Boolean.valueOf(b) instead of new Boolean(b)
Note: however, some classes use a flag and rely on new Boolean() object being
different. A bad practice
synchronized(myInRelServFlg) {
myInRelServFlg = new Boolean(theFlg.booleanValue());
}
- Avoid the use of new String(String)
- Avoid the use of a single character String in a string concatenation. Or better
yet use StringBuilder where possible. Most times the synchronization from
StringBuffer is not required. Sun just released StringBuilder in 1.5, an
unsynchronized variant of StringBuffer.
- Avoid the use of StringBuffer().toString() in string concatenation.
- Avoid creating temproary objects to convert to a String or from a String. E.g. new
Integer(int).toString() and new Integer(String).intValue()
- Use constants for zero length arrays rather than creating the dynamically. Note:
however, some classes use zero length array objects for locks. A bad practice
terminationLock = new int[0];
- Avoid the use of loop to copy arrays, use System.arraycopy() instead.
- Avoid creating an instance of a class just to get the classes name. e.g.
(new java.sql.Date(123456)).getClass().getName ()
-About the history of Vector: Vector was in the 1.0 libraries
By the time of 1.2 ArrayList had come along and people were switching to it for
better performance. Vector was synchronised and because of that slower than the
unsynchronised ArrayList.
By the time of 1.4 however the synchronisation mechanism was much much better -
and Vector actually had a slight performance advantage over ArrayList.
-Performance with inner classes: When considering whether to use an inner class,
keep in mind that application startup time and memory footprint are typically
directly proportional to the number of classes you load. The more classes you
create, the longer your program takes to start up and the more memory it will take.
As an application developer one has to balance this with other design constraints
the person may have. I am not suggesting you turn your application into a single
monolithic class in hopes of cutting down startup time and memory footprint — this
would lead to unnecessary headaches and maintenance burdens.
Does anyone have any comments or other suggestions?
- Use Boolean.valueOf(b) instead of new Boolean(b)
Note: however, some classes use a flag and rely on new Boolean() object being
different. A bad practice
synchronized(myInRelServFlg) {
myInRelServFlg = new Boolean(theFlg.booleanValue());
}
- Avoid the use of new String(String)
- Avoid the use of a single character String in a string concatenation. Or better
yet use StringBuilder where possible. Most times the synchronization from
StringBuffer is not required. Sun just released StringBuilder in 1.5, an
unsynchronized variant of StringBuffer.
- Avoid the use of StringBuffer().toString() in string concatenation.
- Avoid creating temproary objects to convert to a String or from a String. E.g. new
Integer(int).toString() and new Integer(String).intValue()
- Use constants for zero length arrays rather than creating the dynamically. Note:
however, some classes use zero length array objects for locks. A bad practice
terminationLock = new int[0];
- Avoid the use of loop to copy arrays, use System.arraycopy() instead.
- Avoid creating an instance of a class just to get the classes name. e.g.
(new java.sql.Date(123456)).getClass().getName ()
-About the history of Vector: Vector was in the 1.0 libraries
By the time of 1.2 ArrayList had come along and people were switching to it for
better performance. Vector was synchronised and because of that slower than the
unsynchronised ArrayList.
By the time of 1.4 however the synchronisation mechanism was much much better -
and Vector actually had a slight performance advantage over ArrayList.
-Performance with inner classes: When considering whether to use an inner class,
keep in mind that application startup time and memory footprint are typically
directly proportional to the number of classes you load. The more classes you
create, the longer your program takes to start up and the more memory it will take.
As an application developer one has to balance this with other design constraints
the person may have. I am not suggesting you turn your application into a single
monolithic class in hopes of cutting down startup time and memory footprint — this
would lead to unnecessary headaches and maintenance burdens.
Does anyone have any comments or other suggestions?
No comments:
Post a Comment