Commit graph

6 commits

Author SHA1 Message Date
Bartosz Dziewoński
b191e5e860 Use PHP 7 '<=>' operator in 'sort()' callbacks
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.

It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.

* Replace a common pattern like `return $a < $b ? -1 : 1` with the
  new operator (and similar patterns with the variables, the numbers
  or the comparison inverted). Some of the uses were previously not
  correctly handling the variables being equal; this is now
  automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
  $a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
  when both variables are strings, but if any of the variables is not,
  'strcmp()' converts it to a string before comparison, which could
  give different results than '<=>', so changing this would require
  careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
  of the time (returns `1` if `$b` is lesser, and `0` if they are
  equal or `$a` is lesser) but is erroneous.

Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
2018-05-30 18:05:20 -07:00
Timo Tijhof
593442683d benchmarks: Add rate per second and standard deviation to output
* Convert to using RunningStat to ensure mostly constant memory
  usage, instead of storing each result.
* Remove 'median' (no longer possible with this setup).
* Remove 'min' from output.

Change-Id: I6efbc500181eb502c1800165870eee81dbc418a7
2018-01-28 13:49:00 -08:00
Reedy
394f78049e Update RunningStat use statement
Bug: T182273
Change-Id: If9e946e767ca8f4c1af9b1a4855bbbffb98deff5
2018-01-21 04:40:34 +00:00
Umherirrender
f739a8f368 Improve some parameter docs
Add missing @return and @param to function docs and fixed some @param

Change-Id: I810727961057cfdcc274428b239af5975c57468d
2017-09-10 20:32:31 +02:00
Bryan Davis
aaf1e17088 Remove "@author Bryan Davis" and "Brad Jorsch" annotations
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.

Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
2017-06-26 15:25:46 -06:00
Ori Livneh
20abb707ba Decouple Xhprof profiling from profiling data processing
The motivation for this patch came from trying to use xhprof to profile the
unit tests. I was able to profile specific test suites, but if I tried to
profile a complete PHPUnit run, I ended up with empty profiling data. My
initial suspicion was that this was due to some Xhprof buffer getting
exhausted. The actual reason ended up being much simpler: the XhprofTest suite
indirectly called xhprof_enable() / xhprof_disable(), which stopped xhprof and
cleared out the data, so that when I was calling xhprof_disable() at the end of
the run, there was no profiling data to return, because xhprof was not running.

For the most part the XhprofTest was already doing the right thing by trying to
avoid having side-effects or relying on xhprof. Wherever possible, test fixture
profiling data was used in lieu of actually running xhprof. But this was not
totally successful because the Xhprof class coupled the collection of data to
the processing of data. Xhprof::__construct() called xhprof_enable(), so there
was no real way around that.

I think that the right way to fix that is to decouple profiling from profiling
data analysis. Thus I renamed 'Xhprof' to 'XhprofData', and modified the class
so that it expects to be fed profiling data rather than going out and
collecting it on its own. As a result, it is now possible to profile a full
phpunit run with xhprof, and the work that went into writing fixtures for the
Xhprof unit tests pays off: the class and the tests no longer have a hard
dependency on the xhprof extension, and the tests do not have to be skipped
when it is not installed. And the tests are really testing the system under
test, rather than the xhprof extension.

Finally, I added a new Xhprof class, which really is just an extremely thin
wrapper around xhprof_enable() / xhprof_disable(). The only extra functionality
it provides is the ability to check whether xhprof is running, via
Xhprof::isEnabled(). Calling Xhprof::enable() when it is already enabled will
cause an exception to be thrown. This should help us avoid running into
situations where two components contend for control of the profiler without
realizing it. A unit test tests this behavior.

The only part of this change that is not covered by tests is the change to
ProfilerXhprof. I tested it manually and it works.

Change-Id: Ica96beded68f04083abaf48ef1ae8c726eb60fa6
2016-05-12 22:23:05 +00:00