In article <u9KdnQH79aNSEp_PnZ2dnUVZ8n2dnZ2d@bt.com>,
lipska the kat <"nospam at neversurrender dot co dot uk"> wrote:
On 07/08/13 08:44, Sebastian wrote:
@Override
public int compare(AttrValue o1, AttrValue o2)
{
Long ts1 = o1.getEffectiveSequenceNumber(); // ??
Long ts2 = o2.getEffectiveSequenceNumber(); // ??
return ts1.compareTo(ts2);
}
Would you expect a measureable impact of creating these
variables ts1, ts2, instead of "inlining" the calls to
getEffectiveSequenceNumber(). (Using JDK 6?)
How can I reason about this things, probably influenced by
JIT, without doing actually measurements, say as part of a
code inspection?
Have you heard of a profiler?
A few years ago I used one to investigate an application running on
Weblogic application server, the results were eye opening.
I seem to remember the company I was working for handed over a large wad
of cash to get a couple of licences for a commercial product ... can't
remember what it was called unfortunately.
Googling 'java profiler' today returns the usual plethora of hits and I
expect the game has moved on since I last used one, there also appear to
be a bunch of free ones out there.
If you want to reason about this stuff then it might pay you to have a
look at your application with a profiler, you will almost certainly
learn something to help you in your endeavors.
lipska
Most automatic Java profilers are a waste of effort. There are two
methods supported by the JVM:
1) Profiler instrumentation. This rewrites methods to contain timing
calls. This rewriting and data collection breaks all the optimizations
that are critical to Java performing well. Most can only collect data
into a single thread so all concurrency is gone too. These only work
when manually configured to target very specific points of code.
2) Sampling. This takes rapid stack snapshots of each thread and
collects statistics. It's simple and you can even build a JSP to do it.
This also doesn't work for performance benchmarking because snapshots of
native code require threads to stop at a safepoint. When HotSpot is
doing a good job, safepoints come at regular intervals in the optimized
native code, not your source code. When I use sampling profiling on a
project at work, Integer.hashCode() sometimes leaps to the #1 spot.
There's not actually any code in that method and it's not called very
frequently, but often a safepoint's native address maps to that source
in the debug symbol table. Sampling is best for finding code that
pauses (I/O, semaphore, waiting for resource, etc.) for unexpectedly
long times.
As for the original question, variable declarations mean nothing in
compiled code. They're just for humans. At times when AttrValue is
known to have only one possible implementation, HotSpot may even inline
the methods and use direct field access. Later when AttrValue may have
more than one implementation, HotSpot can go remove that optimization.
A good alternative to profiling is a related approach, code coverage.
you don't care about timing or performance statistics at all. You
most, it's visual inspection time. Just look at what gets hit most and
that all the dunces are in a confederacy against him.