No resolution in yesterday's meeting. The logs can be found at https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-22.04.html

From the notes it is unclear whether there were new actions. If so, feel free to create them as blocking tasks of this one.

Also, I assigned this RfC to Chad because this is what the wiki page says. Feel free to change it if for whatever reason this is not true today.

From my memory of last night's RFC meeting, there was agreement that:

• using xhprof would be highly desirable
• removing most calls to wfProfileIn/wfProfileOut would be a good thing.
• We want to keep wfProfileIn/wfProfileOut around:
  • for manual sub-function debugging
  • for custom profiling labels (SQL queries, template names)
• the information gathered by explicit wfProfileIn/wfProfileOut should be integrated with the output of xhprof
  • could be done by implementing a hybrid MediaWiki Profiler that does this "after the fact"
  • could also be done be patching/extending xhprof to allow such custom profiling points

The outcome seems to be that this should go ahead, but integrating automatic (function level) and explicit (wfProfileIn) profiling is considered a blocker.

See also: https://gerrit.wikimedia.org/r/#/c/168930/12/includes/libs/Xhprof.php

@aaron has implemented a pure PHP solution for tracing and merging sub-function stats (https://gerrit.wikimedia.org/r/#/c/178293/) so T1325: Get support for xhprof_frame_begin & xhprof_frame_end functions added to XHProf PECL package is no longer seen to be a blocker. It would still be nice to have but there are issues with the HHVM implementation of these functions as well that will keep us from using them for now (T76831& T76830).

See also:

• T1135: Update Profiling RFC with a plan for removing wfProfile*() calls (@bd808).
• T759: xhprof for MW (@tstarling).