This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page.
|Better PHP profiling|
This RFC exists so we can investigate alternative profiling implementations to the one we have now.
Problems the DIY approach solves
- production debugging via
Problems the DIY approach doesn't solve
- DIY approach in MediaWiki is error-prone
- People forget to include closing profiling
- People have to remember to include profiling at all
- Things that might *need* profiling aren't
- DIY might be slower than something built into PHP
Clean up the profiler implementation to decouple the profiling data collection from profiling output reporting. This will allow us to implement an XHProf powered Profiler class that coexists with the current MediaWiki profiling. We want them to coexist because:
- xhprof does better function-level profiling than MediaWiki can
- MediaWiki profiling does better on non-function-level units of work
They can then both utilize the existing text/UDP output formats. Other output formats could be added as well without requiring a new base implementation.
- Separate data collection from reporting Done
- Implement data collection via xhprof Done
- Parser expansion (only used with ?forceprofile=1) less yucky Done
- Remove wfProfileIn()/wfProfileOut() from core classes for function profiling - can probably do this now? Done
- Deprecate wfProfileIn()/wfProfileOut() usage - once core is cleaned up :) ^^
- Kill debug toolbar visualization experiment? - just remove profiling data from it Done
- Find someone interested in making nice visualization tools for xhprof data Done
- xhprof PECL module has some pages for this, but they are pretty crusty and only shipped in the PECL module.
- Chad and Bryan both think that something useful could be built with Elasticsearch as the backing data store
- ProfilerSimpleTrace is an odd duckling Removed