1

I regularly profile my team's high-performance Java program as inefficient functions can cause major slowdowns. To do so, I keep a port open for attaching Java VisualVM using the following Java machine arguments:

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9011 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost

It struck me today: does profiling a Java program -- or simply keeping a port open for the sake of profiling -- introduce further speed reductions? If so, are some methods of profiling more costly than others? What kind of speed reduction or overhead -- e.g., 1% of runtime, 10% of runtime -- is normal to expect?

While my question is intended for the wider Java audience, I'll note that our program a is memory-light but CPU-intensive simulation: specifically, there are an enormous number of small but computationally expensive function calls being perpetually made. Perhaps optimization is expensive in our case given the sheer number of function calls, but less so for others?

Dylan Knowles
  • 2,726
  • 1
  • 26
  • 52
  • 2
    Yes, profiling the system incurs an overhead. Precisely how much depends on too many factors (JVM version, profiler used, number of calls, stack, etc) to reliably predict. However, the overhead should be proportionally constant. – Elliott Frisch May 02 '16 at 06:11
  • Any ballpark estimates? <10%? <3%? I appreciate that there's a lot of factors, but if it's negligible in most cases then I won't lose sleep over it. :) – Dylan Knowles May 02 '16 at 06:53
  • 1
    It's good that you're profiling. That said, when I hear that people are looking for "inefficient" or "slow" functions, I'm concerned because in my experience real performance problems don't take that form. They take a [*more generalized form*](http://stackoverflow.com/a/927773/23771) having to do with *why* time is spent, not *where*. Thinking only of time spent by routines does not expose them. – Mike Dunlavey May 02 '16 at 20:54
  • @MikeDunlavey -- agreed. I know the "why" in our particular case, and due to that the "where" becomes important. Essentially, a big update function is auto-generated by the tool we use, so a combination of (a) making sure its called less, (b) trying to parallelize it where possible, and (c) making sure we slim down any methods inside it is required. – Dylan Knowles May 03 '16 at 01:56

1 Answers1

2

does profiling a Java program

About 10% - 30% depending on what you are doing.

or simply keeping a port open for the sake of profiling

Probably almost no overhead.

is memory-light but CPU-intensive simulation: specifically, there are an enormous number of small but computationally expensive function calls being perpetually made.

I would seriously consider FlightRecorder (from Java 7, better in Java 8). This has much lower overhead, and has much more details CPU recording. IN Java 8 you can run it without any command line arguments added.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 1
    Excellent! I didn't realize that FlightRecorder could do that without command line arguments, nor did I know that it was more efficient. That will make my life easier in other regards as well (port conflicts). Thanks! – Dylan Knowles May 03 '16 at 01:58
  • @DylanKnowles for CPU and memory profiling, Flight Recorder is excellent and built in. – Peter Lawrey May 03 '16 at 09:46
  • Can it do method timing? (E.g., method A takes 30% of execution time, method B takes 10%, etc.) I can't seem to find a way to do this, but perhaps I'm just missing it. – Dylan Knowles May 03 '16 at 23:31
  • 1
    @DylanKnowles it's under the Code tab – Peter Lawrey May 04 '16 at 08:19