This is a big topic to discuss as there are many approaches that involve analyzing the performance of an application starting from profiling the application to finding the bottleneck.
here I am putting some of the basic tricks for improving performance which I learned in my early days in java, I will keep posting some approaches, experience on performance improvement as and when time allows.
for now, here are naive's tips for making your program run faster.
1. Use Bitshift operator
here I am putting some of the basic tricks for improving performance which I learned in my early days in java, I will keep posting some approaches, experience on performance improvement as and when time allows.
for now, here are naive's tips for making your program run faster.
1. Use Bitshift operator
Use bit shift operator for multiplying and divide by 2, computers are very fast with the bitwise operation.
2. Use StringBuilder over String
Use StringBuilder or Stringuffer in place of the string if you are doing lots of string manipulation it will reduce memory by avoiding creating lots of string garbage. If you are using java5 then consider StringBuilder but that is not synchronized so beware.
3. Use final Modifier
3. Use final Modifier
try to make variable, class, method final whenever possible that allows the compiler to do lots of optimization e.g. compile-time binding so you will get faster output.
4. Prefer static method if design allows
4. Prefer static method if design allows
static methods are bonded compile time while nonstatic methods are resolved at runtime based on object type so the static method will be faster than non-static.
5. Avoid method calls on loop
5. Avoid method calls on loop
Don't call methods in for loop for checking condition e.g. length() size() etc.
instead of doing this, use a modified version
for(int i=0; i<vector.size();i++)
int size = vector.size();
for(int i=0; i<size;i++)
if you like to know about FIX protocol and its usage in Electronic trading or Derivatives trading e.g. Futures and options, foreign exchange, and other asset classes, Please see my FIX Protocol Tutorials series.
I have shared my experience in the investment banking and finance domain in the form of a short tutorial and could be used as a starter guide for anyone new in FIX protocol and can complement official FIX Protocol Technical specification in simple words.
If you are going for any FIX Protocol Job Interview you can quickly benefit from my FIX Protocol Interview Questions, those are questions mostly asked in Interviews for a FIX developer position. It does not just help as a quick reference for Interviews but also opens a new area of learning for newcomers.
hope this would be useful.
8 comments :
About 1 - How many times do you know ahead when you are multiplying or dividing by 2 ?
2 - is only needed when doing runtime string manipulation, and you must ensure it capacity, otherwise you will sure have penalty in peroformance by the char array resizing
4 - Doesn't not sustaint an argument at all, you should try to create object and avoid static methods, because the JIT compiler can inline method calls without the need of an static virtual call.
The most important thing you should concern is code redability, and if and only if you find performance problems with a properly code instrumentation then you should start paying attention to these things, otherwhise is a waste of time.
@Anonymous
About 1: Whenever you write '*2' or '/2', I would say!
About 2: The internal char-array will only be resized when the internal buffer "overflows", i.e. depending on your situation.
In principle you are right: Code should be readable for a human being, not for the compiler.
And "don't optimize prematurely!"
None of these tips will matter when using a modern JVM (Hotspot, JRockit, J9), as the JVM will make all those optimizations for you whenever they are applicable. E.g. take #3, the JIT compiler can easily (and will) figure out if your class/method is final, without the need for you to declare it, and generate code accordingly. Should you later load a class that changes this state the JVM will realize this and re-generate the affected code to take the new situation into account.
As suggested, focus on making the code readable, e.g. use final to make a statement about your design/intentions rather than as an optimization.
5.) is just complete BS: have you ever heard of Iterators? ...and if not, have you ever looked at actual, real-world implementations of #size? Not surprisingly, they hardly ever perform some expensive calculations, but usually just return the 'count' field.
And: read the last section of the previous comment, and stop doing such optimizations.
another approach for #5 is
for (int i=0, j=vector.size(); i < j; i++)
the point is to avoid the creation of a variable just to store the number of elements of vector (kinda old school isnt it?)
Did you know that your optimizations are counterproductive ?
- All modern processors are able to divide by 2 as fast as a bit shift. I just benchmarked the performance difference between the two, and I can manage to perform as much divide by two operations than shifting bit operations in the same amount of time in java.
- Did you know that the java compiler automatically compile your code replacing operator like "+" with StringBuilder automatically ?
- statics methods and loops : the JIT will inline mehtods automatically anyway if needed.
Use a profiler, determine what code is consuming the most CPU time, see if it a use case worth improving. And then optimize it. And benchmark it again to see if you have improved.
lots of Anonymous comment but some of them are really great , thanks for for your open feedback guys, yes in today's highly optimized JIT these might be done automatically but I see the value of being known about this.
Thanks
Javin
I don't see the "value" of referring to these tips as "performance" improvements. Optimizations such as removing invariants from loops are fairly universal in just about all modern languages. Divide by two is usually executed via a shift, so you can and should keep your code clean and readable. This article needs a large heading that says "DO NOT IMPLEMENT".
Post a Comment