Best core java training in Bangalore.\n• Students get Live Project to practice\n• Highly talented with 10 Years Experienced Trainer\n• Well Equipped Class Rooms and Lab Facility\n• Java J2EE Sun Certification Guidance Support with Exam Dumps\n• Java Fast Track course available with best Fees\n• Resume & Interviews Preparation Support\n Visit http://infocampus.co.in/java-training-bangalore.html and make an enquiry to get a call back with much more information. Contact 9738001024 and attend demo.\n
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Optimisations in Java
This should be your default in almost all Java code. Try to avoid the
may argue that it is just syntax sugar for a StringBuilder anyway, as
String x = "a" + args.length + "b";
But what happens, if later on, you need to amend your String with
String x = "a" + args.length + "b";
if (args.length == 1)
x = x + args;
needlessly consumes memory off your heap,
putting pressure on your GC. Write this instead:
StringBuilder x = new StringBuilder("a");
if (args.length == 1);
Regular expressions are relatively cheap
and convenient. But if you’re in the N.O.P.E.
branch, they’re about the worst thing you can do.
If you absolutely must use regular expressions in
computation-intensive code sections, at least
cache the Pattern reference instead of compiling it
afresh all the time:
Now, this advice is really not for general
use-cases, but only applicable deep down in a
N.O.P.E. branch. Nonetheless, you should think
about it. Writing Java-5 style foreach loops is
convenient. You can just completely forget about
looping internals, and write:
Some methods are simple expensive.
In our N.O.P.E. branch example, we don’t have
such a method at the leaf, but you may well have
one. Let’s assume your JDBC driver needs to go
through incredible trouble to calculate the value
of ResultSet.wasNull(). Your homegrown SQL
framework code might look like this:
The above example is from jOOQ, which uses a lot
of generics, and thus is forced to use wrapper
types for byte, short, int, and long – at least
before generics will be specialisable in Java 10 and
project Valhalla. But you may not have this
constraint in your code, so you should take all
measures to replace:
Modern functional programming languages
like Scala encourage the use of recursion, as they offer
means of optimising tail-recursing algorithms back into
iterative ones. If your language supports such
optimisations, you might be fine. But even then, the
slightest change of algorithm might produce a branch
that prevents your recursion from being tail-recursive.
Hopefully the compiler will detect this! Otherwise, you
might be wasting a lot of stack frames for something that
might have been implemented using only a few local
When you want to iterate through a
Map, and you need both keys and values, you
must have a very good reason to write the
There are some cases where the
number of possible keys in a map is known in
advance – for instance when using a configuration
map. If that number is relatively small, you should
really consider using EnumSet or EnumMap,
instead of regular HashSet or HashMap instead.
This is easily explained by looking at
If you cannot use an EnumMap, at
least optimise your hashCode() and equals()
methods. A good hashCode() method is essential
because it will prevent further calls to the much
more expensive equals() as it will produce more
distinct hash buckets per set of instances.
Last but not least, there is a thing that
is not Java-related but applies to any language.
Besides, we’re leaving the N.O.P.E. branch as this
advice might just help you move from O(N3) to
O(n log n), or something like that.