Success! D20046 worked to fix the "profiler not sticking across form posts" issue on secure. 🐈

Yeah, I think the issue is:

The "keep the profiler on across form submissions" code isn't working on secure.phabricator.com, even though it works locally and __profile__=page appears on the "Request" tab.

(I'm also open to improvements to the XHProf UI in Phabricator if you plan to use that to store and review profiles. Many obvious features like tagging and API access which would make it more usable for handling profiles of projects other than Phabricator itself are likely very easy to implement. But I'm not sure there's tons of room for real integrations, even if you used everything else in Phabricator, and you may imagine tooling which can't realistically exist in the scope of Phabricator.)

For general context:

(This isn't really very closely related to the Files application anymore, just cleaning up that board a little.)

I have a build of this that technically works now (produces profiles, passes tests, does not segfault when gently poked). It's still extremely really rough so I don't know when I'll clean it up enough to push upstream.

Total cost is about 1.6s. Of this:

This is still a little bit of a pain but far more reasonable now, here's an actual profile:

I didn't "ref" it here, but D17401 sort of technically did this. I'd like to clean it up a bit more before calling this resolved, though -- particularly, this is basically a secret that only I know about.

Some possible approaches here:

For reference, xhprof will not be included in Debian Stretch due to lack of PHP7 support: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846138

keep in mind that that was successfully compiled by removing lots of code https://github.com/RustJason/xhprof/commit/6c473e39fa93fb7f0acc3fae73f626e5c66dff1a and i'm not completely sure of the implications of the changes.

For my (and others') understanding, the discussion is limited to how to make the needed changes BC, otherwise https://github.com/RustJason/xhprof/tree/php7 would be fine? If so, might I suggest a new major version?

I don't think that is going to work here are some things I pulled from the extension migration page (unless we ifdef large blocks of code):

zval

• PHPNG doesn't require any involvement of pointers to pointers to zval. Most occurrences of zval** variables and parameters have to be changed into zval*. The corresponding Z_*_PP() macros that work with such variables should be changed into Z_*_P().
• In many places PHPNG work with zval directly (eliminating need for allocation and deallocation). In these cases corresponding zval* variable should be converted into plain zval, macros that use this variable from Z_*P() into Z_*() and corresponding creation macros from ZVAL_*(var, …) into ZVAL_*(&var, …). Be always careful about passing addresses of zval and & operator. PHPNG almost never require passing address of zval*. In some places & operator should be removed.
• zval allocation macros ALLOC_ZVAL, ALLOC_INIT_ZVAL, MAKE_STD_ZVAL are removed. In most cases their usage indicate that zval* need to be changed into plain zval. Macro INIT_PZVAL is removed as well and its usages in most cases should be just removed.

• If the changes are relatively minor, add a bunch more #ifdefs? We already have some of this to deal with prior API changes, and I believe this approach is historically a standard one across other extensions.
  • If the changes are substantial, maybe we need to get more creative.

@epriestley, due to the fact that the Zend APIs for PHP7+ are different than those in PHP5* how should changes to XHProf be submitted so we don't break stuff?

https://wiki.php.net/phpng-upgrading should contain a lot of relevant information.

--upload-xprofile is definitely more useful overall than --xprofile <file> since 99% of the time I've also done some approximation of that upload dance, it just feels a little weird for some stuff to take --xprofile <file> and some stuff to take --xprofile which takes no argument and means something completely different.

In T9254#133768, @epriestley wrote:

It seems sort-of-nice-to-have to have the raw version, maybe.

Not sure if it would be desirable but perhaps Arcanist would override libphutil's --xprofile and wrap around it to provide the suggested functionality? This is probably too magical. arc --upload-xprofile seems reasonable.

I think --xprofile is provided by libphutil but it doesn't know about Phabricator. It seems sort-of-nice-to-have to have the raw version, maybe. Not sure how easy it is to add --upload-xprofile to arc.

Should be resolved, probably.

Definitely desirable, although some of them (releeph, oauth server, arcanist project edit) might be tricky to test.

There is a manageable number of buildStandardPage callsites, might be easy to remove if there is only 1-2 missing features.

Typically I'd just switch this over to buildApplicationPage and call it a day, but I don't think that works with frame.

I think we can put the frame logic in buildApplicationPage(), and then switch to it. I can tackle that if you aren't sure how to not break stuff.

buildApplicationPage() calls setDeviceReady(true) on the $page, buildStandardPage() does not.

I'm not sure how best to proceed here. What's the difference with buildApplicationPage and buildStandardPage when it comes to device?

Removing $is_framed will break the DarkConsole "XHProf" tab, which loads the profile in an <iframe />.

hmmm maybe this is buildStandardPage thing.

Oh, on an actual mobile device. We should remove that JS check now, I think it's safe globally.

I assume you mean the table? That is our mobile display for tables (scrollable).

Not quite, see https://secure.phabricator.com/xhprof/profile/PHID-FILE-i37p3oetbxkqjt2fs35h/.

Seems working fine now on mobile.

I almost merged them when they popped up. :P

OIC, I am confusing XPHAST and XHPROF tasks, I'm a bit jetlagged it seems. Didn't notice two different tasks here.

Haha, well you know me and killing apps. Always a fan. :-)

This stretches the bounds of imagination, but I can come up with a use: although we do only a tiny amount of this today, a possible use case is that we may take a different server-side rendering pathway for mobile agents than we do for desktop agents in the future. This does technically happen today, but the amount of code involved is tiny, and is unlikely to ever affect a profile.

@joshuaspence my assumption is exactly 0 people use this tool on mobile, And maybe 5 use it on desktop.

Definitely low priority, but why not?

I can't imagine someone using this on mobile, is there a need for it o can't think of?

Qafoolabs mentions a "proposed timing API" in a pull request. I can't seem to find anything about anything having been proposed, but it might be worthwhile to keep that in mind.

I do see that gc_runs and collected are available (via GC_G(...)) unconditionally? It's not much, but it's more than is available now.

What I'm ideally after is gc_check_possible_root (or some similar call) to be a global function pointer which we could rebind like XHProf currently rebinds zend_execute and similar -- basically do this dance:

Pretty sure you've been across the same path as I was, but I want to share my findings just in case someone can find a way to use it:

I poked at this very briefly and didn't immediately see a way to hook the GC from an extension, at least in PHP 5.4.