On Thu, Aug 27, 2009 at 04:50:29PM -0500, Nicolas Williams wrote: > Now, some kinds of programming mistakes can be really hard to correct > down the road, by which I mean that lots of code may need to get > re-factored or re-written. I hope that's not the case here. Has > someone profiled the unduly slow IPS operations to find out what makes > them slow? Has DTrace been brought to bear on the problem? Is it > inefficient algorithms? Python? What? To answer the crucial question > asked above someone must start by profiling IPS.
You're acting under the assumption that someone has actually found a performance problem that they would like identified. If that were the case, many of the developers on this team are plenty capable of using the Python and Solaris tools to analyze the problem. Some of the individuals who would rather not see IPS succeed have engaged in a series of attacks where they claim that IPS is slow, but when pressed for details offer nothing but invective. Many of the major features that we're adding focus on improving our performance. We've continued to make algorithmic improvements. Bart recently committed a fix that substantially reduced our memory usage. I know for a fact that Shawn, Stephen, Bart, and I have spent time with the profiler and DTrace looking at various aspects of performance. Probably other members of the team do this too. Before the six-month releases we make sure to double-check for lurking pathological issues. If you'd like to help look at the performance, I have some DTrace that I can send you, as well as some pointers for using the Python profiler. (The profiler has a huge overhead -- probe effect skews the results pretty substantially -- but it can help you figure out if you're an order of magnitude off of something.) -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
