Hey all As you might know I'm really into tooling. KDevelop, Massif-Visualizer, Gammaray,... and now - Pace.
I've had that idea for some time, after I tried VTune for the first time and was impressed by it. But we all know the shortcomings of that one, like not being able to use it freely and everywhere. I've also tried perf and oprofile but on 64bit (-fomit-frame-pointer is default) they are pretty useless and I never got anything out of them. I've found things like this though: http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in- linux/378024#378024 At work at the KDAB office I've also heard that some are resorting to manual GDB-interrupt "profiling" on embedded devices. That of course is a royal pita and should be automated. Sounds like a job for tooling :) tl;dr; I wrote a gdb-based sampling profiler a few days ago: http://quickgit.kde.org/?p=scratch%2Fmwolff%2Fpace.git It should hopefully work everywhere you can run GDB. The sampling tool (pace- monitor) only depends on QtCore and should be easily deployed to any embedded device that has Qt on it. The GUI (pace) uses KDE, just like massif- visualizer. This is more or less a proof-of-concept so far, you can either start an app via pace-monitor or attach at runtime. Anyways, you'll get a data file that you can then visualize in pace. There you'll get three different views of the sampling data - try it out. My future ideas/todos: - talk with the GDB people, see whether there is some way to get access to GDB data directly, i.e. to take a shortcut in the "gdb -> stdout -> qprocess -> gdbmi parsing -> pace profile" route. Something like "gdb -> pace profile" looks so much better and would of course be much faster I recon. - make it work with a gdbserver, i.e. run pace-monitor locally and gdb server on a remote machine - pace-control similar to callgrind_control, to allow stop/continue/... at runtime - lots of UI work: - better bottom-up model - visualize locking (if possible) - settings: relative/absolute costs, - split model data by thread - filter by module/library - hide third-party-library internals - ... Generally, I'd like others to try it out and give me some feedback. The proof- of-concept works better than assumed but still does not come even near to the level of information vtune provides. Still, I think pace has the potential to become a quick-n-dirty "find bottlenecks" tool. Esp. since you can attach at runtime and the slow-down is not too high, it can be used alongside callgrind (and vtune) for profiling applications. Bye -- Milian Wolff [email protected] http://milianw.de
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
