4 ms·
I am a C++ programmer that agrees with most of what you say except: 5) Performance monitoring, debugging and profiling tools. See how well those compare agains
by papaf 13y ago
I am a C++ programmer that agrees with most of what you say except:
5) Performance monitoring, debugging and profiling tools. See how well those compare against Java's JMX, HPROF, Heap dumps with OQL, MAT, YourKit etc. Just no match unless you are extremely competent and can manage debugging complex production systems without these tools.
I find the C++ tools much better than the Java ones. I was recently tracking down memory use with a C++ client and a Java server (with help from a Java programmer).
I found VisualVM kind of pretty but mostly useless for finding the source of memory use but with C++/valgrind/massif I got the guilty data structure and the calling function on the client side in a few minutes.
- ExpiredLink 13y agoYou are obviously an expert. Java EE programmers need more expertise from people like you.
- Skinney 13y agoHaven't used valgrind, but wouldn't you say this is mostly related to Java/JVM-languages being garbage collected? Since analyzing heavy memory use requires you to look at a lot of garbage as well. Forcing a gc does help, but not enough in my oppinion
- blinkingled 13y agoI bet you can't use Valgrind on Production C++ Server though. You are also limited to the platforms Valgrind runs on. There have been plenty of times I used Xeprof (HPUX) on Java server to profile CPU usage, GC logging parsed by JMeter, on demand heap dumps (MAT) - all in Production to successfully resolve issues. (Browsing the heap dump will tell you exactly where your memory is - duplicated String Buffers, leaked objects etc.) The point is JVM tooling has matured enough that you have plenty of choices - you'll find something that works well even for production uses.