6 ms·

>Profilers are not rocket science... They are not. There are orders of magnitude more rocket scientists than good profiler writers. And no, bottle rockets with

>Profilers are not rocket science... They are not. There are orders of magnitude more rocket scientists than good profiler writers. And no, bottle rockets with flight recorders do not count.

hardware2win 3y ago
"It is not rocket science" is so 1970, I'd say nowadays it is "It is not semiconductor eng."
chrsig 3y ago
What is your criteria for 'good profiler writer'?
- timcobb 3y ago
  I know one when I see one
parttimenerd 3y ago
The number of profiler writers is not too large (if you ignore all the people writing the UIs), but it's the same with compilers: You only need a few to create a useful enough product. There are many more people working on tracing right now. There are even fewer people working on the underlying profiling APIs. I'm one of the few working regularly on the stack walking API that powers most Application Platform Monitors (and async-profiler). I'm the person who writes all the code to test AsyncGetCallTrace currently. If anyone is interested: I wrote a blog post on it https://mostlynerdless.de/blog/2023/03/14/validating-java-profiling-apis/ https://mostlynerdless.de/blog/2023/03/14/validating-java-pr.... I'm writing blog posts on the profiling topic every two weeks (usually publishing them on Monday or Tuesday).
- jpgvm 3y ago
  Such a task is usually thankless work so, thank you. :) I don't doubt my favorite profiler, YourKit also uses your code. Profilers are probably the class of tool that most drastically improved the code I write so if anyone reading hasn't really felt the need to use one, you should. Just a cursory glance can quickly verify assumptions about runtime performance. Even if the code is currently acceptable it helps to be mindful of where cycles are being spent (and lock contention, network blocking, etc) so if you end up doing some refactoring anyway that additional context and knowledge can guide improvements that aren't strictly "performance work".
  - parttimenerd 3y ago
    > Such a task is usually thankless work so, thank you. :) It's just a game of whack-a-mole, finding new segmentation faults and other bugs is quite easy when you know how to write good test code. Fixing the actual bugs less so. But it's fun and I do this for a living in the SapMachine team at SAP SE. > I don't doubt my favorite profiler, YourKit also uses your code. They surely do profit by work improving the profiling APIs. > Just a cursory glance can quickly verify assumptions about runtime performance. Yes. But there aren't enough people educating people on profilers. So I started blogging and talking (https://youtu.be/Fglxqjcq4h0 https://youtu.be/Fglxqjcq4h0) on this topic. Besides fixing all the bugs and implementing my own profile viewer based on FirefoxProfiler (https://plugins.jetbrains.com/plugin/20937-java-jfr-profiler https://plugins.jetbrains.com/plugin/20937-java-jfr-profiler).
    - jpgvm 3y ago
      That is awesome, I will be sure to checkout your viewer.

>Profilers are not rocket science... They are not. There are orders of magnitude more rocket scientists than good profiler writers. And no, bottle rockets with flight recorders do not count.

hardware2win 3y ago

"It is not rocket science" is so 1970, I'd say nowadays it is "It is not semiconductor eng."

chrsig 3y ago

What is your criteria for 'good profiler writer'?

timcobb 3y ago
I know one when I see one

parttimenerd 3y ago

The number of profiler writers is not too large (if you ignore all the people writing the UIs), but it's the same with compilers: You only need a few to create a useful enough product. There are many more people working on tracing right now. There are even fewer people working on the underlying profiling APIs. I'm one of the few working regularly on the stack walking API that powers most Application Platform Monitors (and async-profiler). I'm the person who writes all the code to test AsyncGetCallTrace currently. If anyone is interested: I wrote a blog post on it https://mostlynerdless.de/blog/2023/03/14/validating-java-profiling-apis/ https://mostlynerdless.de/blog/2023/03/14/validating-java-pr.... I'm writing blog posts on the profiling topic every two weeks (usually publishing them on Monday or Tuesday).

jpgvm 3y ago
Such a task is usually thankless work so, thank you. :) I don't doubt my favorite profiler, YourKit also uses your code. Profilers are probably the class of tool that most drastically improved the code I write so if anyone reading hasn't really felt the need to use one, you should. Just a cursory glance can quickly verify assumptions about runtime performance. Even if the code is currently acceptable it helps to be mindful of where cycles are being spent (and lock contention, network blocking, etc) so if you end up doing some refactoring anyway that additional context and knowledge can guide improvements that aren't strictly "performance work".
- parttimenerd 3y ago
  > Such a task is usually thankless work so, thank you. :) It's just a game of whack-a-mole, finding new segmentation faults and other bugs is quite easy when you know how to write good test code. Fixing the actual bugs less so. But it's fun and I do this for a living in the SapMachine team at SAP SE. > I don't doubt my favorite profiler, YourKit also uses your code. They surely do profit by work improving the profiling APIs. > Just a cursory glance can quickly verify assumptions about runtime performance. Yes. But there aren't enough people educating people on profilers. So I started blogging and talking (https://youtu.be/Fglxqjcq4h0 https://youtu.be/Fglxqjcq4h0) on this topic. Besides fixing all the bugs and implementing my own profile viewer based on FirefoxProfiler (https://plugins.jetbrains.com/plugin/20937-java-jfr-profiler https://plugins.jetbrains.com/plugin/20937-java-jfr-profiler).
  - jpgvm 3y ago
    That is awesome, I will be sure to checkout your viewer.