Matthew Allum <[EMAIL PROTECTED]> writes: > But I think the difference here is, and a point you've very well made, > is sysprof is designed for desktop type hardware - thats not (usually) > ARM. On ARM we *need* features that oprofile gives us like use of > hardware foo to lower overhead and the data collection separation. > Porting sysprof to ARM as to be useful would likely break your original > design goals.
I wouldn't say that sysprof is designed for desktop type _hardware_, as much as it is designed for desktop developers. After all, an ARM of today is as powerful as a desktop not that many years ago, and sysprof actually goes to quite some length to limit the amount of CPU and memory it uses. I don't really see the overhead of using a timer interrupt rather than a "counter-overflow" interrupt; in fact I would expect that actually walking the stack would be the thing that dominated, not the handling of the interrupt. I'll admit though that sysprof at the moment requires a system call per sample which oprofile doesn't. I should probably fix that. Also note that cvs HEAD of sysprof actually does have separation of collection and analysis. There is a command line tool, sysprof-text, producing files that can be loaded by the graphical tool. > Sysprof does make more sense for your average developer, who just wants > to profile his code with the minimum amount of hassle, but on the > *desktop*. On embedded, where its a different set of constraints, > oprofile currently makes more sense. Feel free to use whatever makes more sense. In the end I care a lot more about people doing useful optimizations, than I do about what tools they use. What I objected to, and still object to, is the idea that oprofile is "technically better". The features that the oprofile kernel module has over the sysprof module (such as the ability to use cache miss and branch misprediction counters) are quite simply not useful for what sysprof tries to do. Soren _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
