Java Performance tuning-contd..
One can choose a JDK version(vendor) for compilation and another JRE version(vendor) for execution.
Understand the GC pattern of the application.Adjust GC interval and -Xmx if it helps, after looking at the pattern. Use trial and error to set this values.
Casting is an overhead. If all the list objects are one type, they better be declared as a collection of that type.Casts(not resolvable at compile time-using instanceof operator) have runtime memory cost.
Is the development VM same as the production VM?
JIT compiler, compiles bytecode into machine native code on first execution.
Bytecode interpretor executes by decoding,converting into native code and then executing.
Shared libraries can be loaded into system memory even before application startup to application reduce startup time.
Some compilers have the optimise option (-O) meant to compile such that execution optimisations can be applied.
You could compile to native machine code directly.
-J and -target options exist during compilation.
Running application with -verbose option give insight into the loading..etc.
Translators exist that convert Java program to C.
Class loading times improve if jar packaged.
adaptive optimisation
Optimizing compilers cannot change your code to use a better algorithm.
Ask/Decompile to know what the application is doing under the hoot. Don't assume.
Class.forName dynamically loads libraries and can be time consuming.
compilers compute runtime code path tree.
Code motion moves calculations out of loops that need calculating only once.
Obfuscation makes code tough to understand after decompiling and has also can have performance gains.
Check the application startup parameters.
Java does not prevent you from using excessive amounts of memory.
Check object creation and know why they are being created.
Container object can be pool managed by custom defined classes. Ex:VectorPoolManager
Early initialization involves creating objects before they are used and is used when large number of objects are needed. Late initialization involves delaying object creation till it is absolutely necessary thereby avoiding unnecessary object creation.
Throwing an exception and executing the catch block has a significant overhead. This overhead
seems to be due mainly to the cost of getting a snapshot of the stack when the exception is created (the snapshot allows the stack trace to be printed). The cost is large: exceptions should not be thrown as part of the normal code path of your application unless you have factored it in.
Local (temporary) variables and method-argument variables are the fastest variables to access and
update.
Instance and static variables can be up to an order of magnitude slower to operate on when
compared to method arguments and local variables.
ints are normally the fastest variable type to operate on. longs and doubles can take longer to
access and update than other variables because they are twice the basic storage length for Java
(which is four bytes).The specification allows the actual manipulation of longs and doubles to be
implementation- and processor-dependent, so you cannot assume longs and doubles always take
longer.
Understand the GC pattern of the application.Adjust GC interval and -Xmx if it helps, after looking at the pattern. Use trial and error to set this values.
Casting is an overhead. If all the list objects are one type, they better be declared as a collection of that type.Casts(not resolvable at compile time-using instanceof operator) have runtime memory cost.
Is the development VM same as the production VM?
JIT compiler, compiles bytecode into machine native code on first execution.
Bytecode interpretor executes by decoding,converting into native code and then executing.
Shared libraries can be loaded into system memory even before application startup to application reduce startup time.
Some compilers have the optimise option (-O) meant to compile such that execution optimisations can be applied.
You could compile to native machine code directly.
-J and -target options exist during compilation.
Running application with -verbose option give insight into the loading..etc.
Translators exist that convert Java program to C.
Class loading times improve if jar packaged.
adaptive optimisation
Optimizing compilers cannot change your code to use a better algorithm.
Ask/Decompile to know what the application is doing under the hoot. Don't assume.
Class.forName dynamically loads libraries and can be time consuming.
compilers compute runtime code path tree.
Code motion moves calculations out of loops that need calculating only once.
Obfuscation makes code tough to understand after decompiling and has also can have performance gains.
Check the application startup parameters.
Java does not prevent you from using excessive amounts of memory.
Check object creation and know why they are being created.
Container object can be pool managed by custom defined classes. Ex:VectorPoolManager
Early initialization involves creating objects before they are used and is used when large number of objects are needed. Late initialization involves delaying object creation till it is absolutely necessary thereby avoiding unnecessary object creation.
Throwing an exception and executing the catch block has a significant overhead. This overhead
seems to be due mainly to the cost of getting a snapshot of the stack when the exception is created (the snapshot allows the stack trace to be printed). The cost is large: exceptions should not be thrown as part of the normal code path of your application unless you have factored it in.
Local (temporary) variables and method-argument variables are the fastest variables to access and
update.
Instance and static variables can be up to an order of magnitude slower to operate on when
compared to method arguments and local variables.
ints are normally the fastest variable type to operate on. longs and doubles can take longer to
access and update than other variables because they are twice the basic storage length for Java
(which is four bytes).The specification allows the actual manipulation of longs and doubles to be
implementation- and processor-dependent, so you cannot assume longs and doubles always take
longer.
Comments