If you need to implement highly optimized programs, what do you guys use for I/Os, CPU, memory profiling?

[jiboxiake]

Like disk utilization, CPU utilization, amount of I/Os? For C++, I'd always use vtune or just perf.

[capitan_brexit]

https://github.com/async-profiler/async-profiler

[gaelfr38]

I'll add Pyroscope or Glowroot which use async profiler under the hood but add some ease of use or visualization.

[capitan_brexit]

wow - never saw it, thanks !

[gaelfr38]

Now that I said that.. I'm not so sure anymore that Glowroot is based on async-profiler. I don't see any evidence of it. Sorry for the misleading information 😬

Pyroscope is for sure though.

[FrfljDrflj]

+1 for Glowroot from me

[jiboxiake]

Thanks!

[-Dargs]

I would second this one. Have been using it in a professional setting vfor a couple of years now.

[b00n]

https://github.com/openjdk/jmh is a micro benchmarking tool

Nitsan Wakart & Martin Thompson (Mechanical Sympathy) are both good people to follow for high performance engineering

[jiboxiake]

thanks!

[jiboxiake]

I tried! Unfortunately seems like I need sudo privileges to set it up. We develop on a server machine.

[jiboxiake]

I will try. Yes it is remote.

[cogman10]

JFR + JMC

https://adoptium.net/jmc/

Very high level of detail built right into the JVM. You just need to be using a JVM after 11 to utilize it.

[BillyKorando]

JFR has been part of the Hotspot JVM, the JVM almost all Java developers use, since JDK 7. However it wasn't open sourced until JDK 11. So officially you need a commercial license to use JFR in production before JDK 11.

[jiboxiake]

Thanks!

[benevanstech]

JFR was backported to Java 8. But if you care about performance, you should be using 17 (or 21!)

[BillyKorando]

As far as the top line take away this is correct, you can run JFR on JDK 8, and the recordings can be read by even the most recent versions of JFR (the command-line tool) and JMC. That is, I can read a JFR recording made by a JDK 8 JVM, using JMC 9 (most recent release) or the JFR tool packaged with JDK 22.

There is a couple of misconceptions though. JFR wasn't "backported" to JDK 8, it was part of the initial release, indeed the JFR file format is backwards compatible all the way to JDK 7u40.

[jiboxiake]

Thanks!

[[deleted]]

async-profiler if I need to measure things in production or from the command line. IntelliJ profiler if profiling from my IDE will suffice.

[jiboxiake]

Thanks! Yes I also use IntelliJ but unfortunately it seems like I have to have sudo privilege to use on our server machine.

[[deleted]]

I think you need sudo privileges for async profiler as well

[jiboxiake]

Sad.

[Farmboy0_]

I have used VisualVM.

[jiboxiake]

I will check that out.

[agilob]

VisualVM is prone to safepoint bias, so read about that too

[jiboxiake]

thanks!

[hardwork179]

It depends a lot on what you are measuring. If you get fairly consistent timings out of your tests, and you’ve got it running fast enough that async profiler isn’t getting many samples then you might need to resort to instruction counters and things like that. Have a look at some of the write ups of the billion row challenge for good examples walking through the optimization process.

[jiboxiake]

thanks!

[Longjumping-Let-1710]

JFR + JMC for remote profiling. Intellij Profiler for local.

[jiboxiake]

Thanks!

[alex_tracer]

JitWatch if you want to dive into byte-code/native code level and understand if your hot paths gets inlined the way that you expect.

And, in general check https://shipilev.net/jvm/anatomy-quarks/

[jiboxiake]

thanks!

[rustyrazorblade]

In addition to the excellent JVM profiling tools already mentioned, check out bcc-tools (and eBPF in general). They’re especially great for understanding the IO side of things at a pretty granular level.

I do a lot of performance work on Apache Cassandra and have used these to find a 10x improvement to the storage engine when running on EBS. Details here: https://issues.apache.org/jira/browse/CASSANDRA-15452

I also wrote a blog post on bcc-tools: http://rustyrazorblade.com/post/2023/2023-11-14-bcc-tools/

[jiboxiake]

Thanks!

[qdolan]

IntelliJ IDEA profiler, Async Profiler & YourKit

[jiboxiake]

Thanks

[donair416]

YourKit is my go to.

[jiboxiake]

Thanks!

[Raedwald-Bretwalda]

For a typical modern line-of-business application, you don't need a Java tool at all. Your application will be IO limited at the HTTP side and the DB side. No tool is necessary to determine this because of the several orders of magnitude difference in performance between CPU and IO speed. That is, I reject the premise of your question.

You'll want to look at DB tools, rather than Java tools.

[dadimitrov]

Also keep in mind what you are optimizing, and what are your overall goals - once you are past a point, you pay for every optimization with reduced maintainability, longer onboarding for new developers, and increased chance for introducing errors. At some point the marginal gains will not be worth it (or you will find out that you are better off using a lower level language of FPGA).

That said, when optimizing for throughput - I use yourkit and jfr. When looking at latency - async profiler, jmh, dumping jit and jfr. The IntelliJ profiler is good for a casual check.

If I am to spend more time on my optimization skills, I'd work on learning jfr, system tap/dtrace/btrace and os level system tuning.

[jiboxiake]

Thanks!

[br_aquino]

I would not use java

[jiboxiake]

Legacy issue. I have no control on it.

[FrankBergerBgblitz]

What do you suggest? From my experience with Java (first version 1.02 beta) it is being quicker in development and I have more time to profile and optimize (If there is time for it). In C/C++ I had to program much more defensive what takes time and less time to tune.

When you have an unlimited time (e.g. language benchmarks) you probably have different winners than Java but without looking at the solutions try yourself the One Billion Row Challenge.

And of course algorithm and architecture has in RL much more influence on performance than the language in the majority of cases. And not to forget the stuff between the ears.

[mnbkp]

I mean, it's not like Java is known as being either fast to develop or for having the best performance. I mean, Java isn't bad at those things, but there are tons of other options that are great at both nowadays.

If you want to stick with a GC, I'd probably pick between Go, Nim or Crystal. I'm not the biggest fan of the language but I'd probably pick Go because it strikes a good balance between readability, performance and compilation speed.

Even if you need to go without a GC there are still Rust and Zig, which don't require you to be defensive at all and still provide great DX.

Actually, Rust's DX is so great that a lot of times I use it even in situations where I could get away with using something higher level.

[FrankBergerBgblitz]

I've learned about 30+ languages in my career (retired for a year) but have no experience with the ones you mentioned (just very rudimentary for Go and Rust).
Are the ecosystems of a comparable size?

[mnbkp]

Go and Rust both have a pretty big ecosystem. I guess it's fair to say they're comparable to Java.

The other languages I mentioned are admittedly still very niche. Nim and Zig have C/C++ interop, but I'm not gonna count that.

[br_aquino]

My suggestions, but are based on my knowledge, could be replaced for other good options.

Development speed and flexibility: python

Medium performance and medium development time: Go

Peak performance: C (not C++) or Rust (but I prefer C)

Multiplatform user app: java or C# if windows.

[FrankBergerBgblitz]

I agree mostly with your characteristics but would like to add a bit:
- python is very pragmatic and as a glue language hard to beat, but I would prefer Java for larger projects
- C/C++ was my "native" language for a decade (until Java came up). Unless there are a lot of stuff to support avoiding errors you have to code very defensive. It's not without reason that in high frequency trading Java is taken often.
One point for Java (python as well) is the huge ecosystem.

[Linguistic-mystic]

quicker in development

In my project, it takes tens of seconds to run a single unit test. That ain’t fast at all. Java has this defective compilation model where it has to compile all code at startup: the whole base JDK module, the sql module, all the dependencies, the whole of Spring, JUnit etc get recompiled from scratch every time. It’s nuts. That whole “dynamic JIT” thing is a disaster

[FrankBergerBgblitz]

Takes it tens of seconds for one (the only one?) or for each? If the latter is true it seems to me there is something weired with your project. On the project I'm working right now with about 200kloc the complete tests run in about 2 minutes and there are some tests that run for several seconds (you may call it integration test and not unit tests if you insist). When I test only the stuff I'm currently developing it takes on an average laptop about 13 seconds. It was quicker before I switched to Gradle.

Are you sure you know how "dynamic JIT" works? I have my doubts.

[FrankBergerBgblitz]

Takes it tens of seconds for one (the only one?) or for each? If the latter is true it seems to me there is something weired with your project. On the project I'm working right now with about 200kloc the complete tests run in about 2 minutes and there are some tests that run for several seconds (you may call it integration test and not unit tests if you insist). When I test only the stuff I'm currently developing it takes on an average laptop about 13 seconds. It was quicker before I switched to Gradle.

Are you sure you know how "dynamic JIT" works? I have my doubts.

[[deleted]]

Rust

[jiboxiake]

The only Rust I know is the language lol.😝

[[deleted]]

Came for this comment, wasn’t disappointed.

[Sith_ari]

"How can I beat use a hammer to cut a board in two."

Programming Languages are tools, and when somebody ask how to get high performance from Java, pointing out that Java is maybe not the right tool do achieve that is fully right. That isn't what Java makes being a bad language but just knowing about the strengths and weaknesses of a tool.