Hacker News Reader

Comment by IshKebab | Hacker News Reader

Damn I hate it when you write a whole project and someone comes along and says "this already exists" and you realise how much time you wasted (yeah even if some of it counts towards learning I'd still rather not needlessly repeat other people's work).

Anyway, pprof has a fantastic interactive Flamegraph viewer that lets you narrow down to specific functions. It's really very good, I would use that.

https://github.com/google/pprof

Run `pprof -http=:` on a profile and you get a web interface with the Flamegraph, call graph, line based profiling etc.

It's demonstrated in this video.

https://youtu.be/v6skRrlXsjY

They only show a very simple example and no zooming, but it works very well with huge flamegraphs.

View on HN

    I tried to find something fast and native. Saying "native" I mean something which doesn't require a browser.

Uses a browser which doesn't meet the requirements they set.

Yep. Personally I love the Firefox profiler for interacting with perf - since it can show you flame graphs and let you explore a perf trace by dominators and whatnot.

But I applaud the effort to make small, native apps. I agree with the author - not everything should live in the browser.

I think they were saying "fast and native" because web things usually aren't fast. In this case it is though, so I don't see why it would be a problem for it to be web based.

I said "fast and native" because none of browsers made it impossible to inspect the flamegraph.

> In this case it is though, so I don't see why it would be a problem for it to be web based.

Would you like to say that your browser is able to render the flamegraph https://laladrik.xyz/img/pic.svg and inspect it? As I wrote in the article (the first paragraph), it takes a couple of seconds to render the graph, and nothing happens when I press on a frame. Could you check it, please? If your browser renders it as fast enough and allows to open a frame, please, let me know how could I improve any of browsers. I would really appreciate it.

I can really recommend samply: https://github.com/mstange/samply. It just works out of the box.

It uses the Firefox profiler to view its recorded profiles. You can (don't have to, just can) even share them, I was looking at this profile just yesterday: https://share.firefox.dev/3PxfriB for my day job, for example.

MacOS Instruments is really quite good.

I have a `profile` function I use.

    fn profile() {
        xcrun xctrace record --template 'Time Profiler' --launch -- $@
    }

Then I just do:

    $ profile ./my-binary -a -b -c "foo bar"

or w/e and when it completes (can be one-time run or long-running / interactive) now I have a great native experience exploring the profile.

All the normal bells and whistles are there and I can double click on something and see it inline in the source code with per-line (cumulative) timings.

> MacOS Instruments is really quite good.

It really isn't. It's probably the slowest profiler UI I've ever used (it loves to beachball…), it hardly has any hardware performance counters, and its actual profiling core (xctrace) is… just really buggy? After the fifth time where it told me “this function uses 5% CPU” and you optimize it away and absolutely nothing happened, because it was just another Instruments mirage. Or the time where it told me opening a file on iOS took 1000+ ms, but that was just because its end timestamps were pure fabrications.

Maybe it's better if you have toy examples, but for large applications, it's among the worst profilers I've ever seen along almost every axis. I'll give you that gprof is worse, though…

I love pprof. I used it so many times to profile my Go applications. However, as you wrote, the visualization is in a browser, which I found incapable to render the flamegraphs I had to work with.

Reply on news.ycombinator.com