Caveat: I use oprofile every couple of days, and I helped write some of the drivers for it. Still, I'm sympathetic to complaints about it. From what I've observed:
- There's a lot of drift between userspace and kernelspace. Event names and communication mechanisms seem to change from release to release. I've had to edit the shell scripts and source code repeatedly on installed versions.
- Apparently the kernel people wanted a much faster cycle time on new hardware support, and oprofile userspace is "lightly maintained". This hasn't been as much of a problem for me since I stay behind the curve intentionally, and mostly just want to monitor clocks, CPI, and crude cache and branch-mispredict hotspots; but I also know where to patch in userspace if necessary.
- There is further drift against libbfd, gcc, and the various toolchain pieces involved in mapping samples to reasonable debug information. I don't expect the kernel developers to do much more on this than snark about how userspace sucks; but who knows, maybe they'll write another toolchain and be free at last.
- The drift has been sufficiently bad that most non-kernel, non-oprofile developers on linux I talk to have no idea how to "get oprofile working" and need to be hand-held through it. And when they do get it working and it suddenly stops (or lies, which it can do if the drift is *just shy* of enough to break it), they don't know how to fix it.
- As an additional data point, I've seen two (perhaps three now?) separate projects spring up that ship *both* their own batch of replacement userspace tools *and* their own forked copy of the oprofile kernel module, in order to keep the interface, expectations and capabilities pinned down.
All that aside though, I really do use oprofile all the time and find it (and kcachegrind) *way* more useful for performance tuning than, say, shark or vtune. Totally worth the price of admission. The other-platform competition seems to lie, crash, wedge, and otherwise misbehave even worse.