On 11/03/2010 11:48 AM, Owen Taylor wrote: > Lack of decent profiling is a major problem for making our operating > system fast. By far the most effective of profiling is sampling profile > with callgraph information. I am the author of tsprof, http://bitwagon.com/tsprof/tsprof.html . Eight years ago that app provided everything you desire, and with no compilation flags necessary: not -pg, not -p. [The implementation is equivalent to "infecting the memory image of the application with a profiling virus" and it was at process entry in just a couple seconds.] But nobody would pay for it on i686, so the product was abandoned despite a working prototype for x86_64. A few years before that, there was TracePoint Technology, a startup funded by venture capital that offered nifty profiling tools: http://venturebeatprofiles.com/company/profile/tracepoint-technology Soon they were acquired by Digital Equipment Corp and died with DEC. Over several years, dueling proposals (perfctr, perfmon, perfmon2) failed to get into the Linux kernel. Then the CPU and motherboard designers made the underlying hardware counter (RDTSC) unreliable in too many cases (non-constant frequency, not synchronized for SMP, arbitrarily scribbled by SystemManagementMode, ...). Today the infrastructure work for kernel ftrace comes close to what is required for use by apps, but gcc still won't do exactly the right thing. In short, those who want profiling have failed repeatedly to present an _effective_ case. What are you doing to do differently this time? [The workaround is to spend a week learning how to run oprofile and interpret its output.] -- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
