This new parameter / property will decide if we want to reduce
the run data before processing it:
- By default it will be disabled in table mode.
- By default it will be enabled in graph mode.
- The defaults can be changed by adding reducedata=[0|1] in the URLs
- Once data reduction is enabled, it stays enabled while
navigating within the xhprof reports.
This covers the 2 new functions with unit tests:
- xhprof_topo_sort()
- reduce_run_data()
Note that the example graph used in the provider is the
one shown in the issue to explain the reduction procedure.
Here we are reducing the xhprof runs data by removing the
__Mustache==>__Mustache calls and all the orphaned data.
To save N iterations what we are doing is:
0. The information is "topologically" sorted, so we ensure that
all the parents in the data are processed before the children.
(this will help a lot when cleaning orphaned data, see below).
1. First pass, all the candidate (by regexp) calls are removed
from the run data.
2. Second pass, all the orphaned information (calls that have
ended losing his parent) are also removed, so data is consistent.
Note that, normally we would need N passes to remove all the
orphaned data (because each pass creates new orphan candidates),
but, as far as we have ensured that the information is topologically
sorted (see point 0 above), all this can be done in one unique pass.
TODO:
- Add unit tests.
- Enable some system to be able to decide which utilities we
want to get the data reduced and which ones will continue
using the complete data. Right now the reduction is being
applied to all the utilities (both table and graph views).
- Document the change and, if implemented, the way to select
between complete/reduced data.
- Consider adding some caching to speed-up the reduction process
(some TODOs have been left in the code pointing to the critical
points).
This will allow the use of other storage systems implemented
in plugins.
It also allows for disabling the built in DB based profiling, which
will be useful when using an external target to not waste DB storage.
Enable util scripts to be profiled again and ensure
that non-util script runs that don't include version.php
are also able to provide some output.
See David's commit for how export ensures version is used.
To support PHPUnit we need to support large profiles, these may
include backups and restores. To do that the following was required;
- gzcompress for database space saving.
- gzcompress for XML DomDocument field to say < 10Mb and allow imports.
- Save PHPUnit runs directly to a file so they can be imported to the normal database.
- Memory allowance on profiling view pages increases to support large profiles.
PHP7 doesn't have any default XHProf support and all other
investigated forks don't have stable PHP7. Tideways is under
active development and is easy to install. The data format
is compatible with XHProf so it is a drop-in replacement in that way.
The box API was used with an extra incorrect parameter
in the profiling code. It worked without issue until
the introduction of error checking in MDL-40842. It
has failed since then.
Note this continues being version 0.9.2 and
only a few changes have landed since 3y ago.
(the important stuff is in the xhprof extension,
not in this UI package using it)
This allows profiling to be started earlier in the
setup.php execution, by configuring everything in
the config.php file. That way some interesting code
is also profiled, like DB connections, load of config records...
100% compatible with normal profiling and enabled via
special setting $CFG->earlyprofilingenabled
Example (to be put on config.php):
$CFG->earlyprofilingenabled = true;
$CFG->profilingautofrec = 3;
$CFG->profilingincluded = '/*';
$CFG->profilingallowme = true;
(to enable early profiling for 1/3 of any requests while also
allowing to use the PROFILEME PGC)
