Glyph Lefkowitz <gl...@twistedmatrix.com> added the comment: Charles-François: > Also, I must admit I'm quite skeptical about the real benefit of explicit probes for user-land, especially for CPython which isn't used for performance-critical systems...
I beg to differ. CPython is totally used on performance-critical systems, and I know I'm not the only user who thinks that. "Performance-critical" doesn't necessarily mean "goes as fast as it ever possibly can", clearly PyPy is the place to go for that, but "can process at least X work in Y time". Meeting performance goals with CPython is already challenging enough, please don't make it artificially hard by refusing to integrate tools which help users understand and improve performance. Benjamin: > I'm -1 on this patch for essentially the same reasons as Charles-François. It > introduces a lot of code (and hacks!) in critical pathways of the > interpreter. Someone would have to be constantly maintaining and testing it. > In return, what do we get? You get support for a highly sophisticated and low-impact profiling and tracing technology which provides support for illuminating performance problems *as well as* complicated behavioral problems that only happen under load, without slowing down the interpreter as a whole. Not to mention possible integration with a whole slew of tools that know how to deal with data from that system. I'm not saying that this is necessarily worth the maintenance burden; your analysis of the tradeoff may ultimately be correct. I can't presume to know that because I am not intimately familiar with all the code it touches. But it's definitely not nothing. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
