Good questions. I have more an intuitive understanding of the tuning process, but haven't tried to articulate it in any detail. I suspect profiling is different things to different people, but most people would agree that it encompasses performance monitoring.
Here is the wikipedia definition of profiler:
In software engineering, program profiling, software profiling or simply profiling, a form of dynamic program analysis (as opposed to static code analysis), is the investigation of a program's behavior using information gathered as the program executes. The usual purpose of this analysis is to determine which sections of a program to optimize - to increase its overall speed, decrease its memory requirement or sometimes both.
<<what is the main idea of using the profiler?>>
Using a profiler allows you to see which part of your code takes the most time. This isn't always often as you may have a very fast routine, but it is invoked millions of times and another one that takes a long time but is only invoked once. In this case it would probably make more sense to tune the faster routine. It is also difficult to guess which routines will be slow just by looking at them. Often our intuition on where to tune is wrong. A profiler helps overcome this weakness by putting a little science and analysis behind what we tune. Plus it gives us a baseline that allows us to compare performance over different iterations as the program evolves.
I think of a profiler as more of a development and
test activity, but it is also important to monitor in production as often real users can do surprising things with an application. Also, I think of profilers as more of a performance tool. As you mention there are other aspects to testing your code that are important such as bandwidth consumption, cpu utilization, memory usage, object creation, IO, code coverage, exception tracking and no double more. Something
you should also gain in the process isn't really a number, but a better understanding of the normal operations of your system including which subsystems are most popular, and what features are overly complicated. All of this knowledge is powerful downstream when you need to trouble shoot any problems that may arise.
I would be curious to hear from other people if the term 'profiler' covers all these and if not, is there a term that encompasses all of these concepts. Some 'profilers' do more than others. Essentially it is Metrics based testing and tracking.
<<Here some points as far as I understand by myself:
- find method with the longest execution time>>
Total execution time is probably more important that longest execution time.
<<- find redundant method calls>>
Not sure what you mean by redundant method calls.
<<- find redundant object instances>>
I am guessing you mean situations where a large number of objects are created. Some profilers do this others don't.
<<What else?
How can I use the memory statistics?
How can I identify the memory leaks?
>>
All of these are important. Again some profilers do this others don't.
<<Is there any books with some words about the basics of Java performance?>>
I haven't read any in a while, but back in the day there was 'Java Performance Tuning'. It would be nice if there was a book that talked more about software runtime metrics, tracking and monitoring in general. Is there one?
<<2) If I use executable JAR or even compile EXE file, whether the performance is to be reduced or raised?>>
Depends on the situation I am sure. Usually your best tuning tip is writing good maintainable, changeable code and profiling it to see where to tune. This can give orders of magnitude improvement whereas compiling to an exe would probably give incremental improvements. Two easy things I have done that made big impacts on performance: 1)using the lastest jvm (overall each version from 1.1, 1.2, 1.4, 1.5, 1.6 and now 1.7 all seem to get faster). 2) running your code with the -server option. Of course these aren't universal solutions and should be tested on your code.
Also read the java performance tuning faq below.