PHP function speed analysis tool

Recently, I paid attention to the materials on performance and speed measurements of PHP functions. After analyzing a number of materials, the following conclusion was made. There are quite a few comparisons, but all measurements are carried out with different input conditions, the output of test results is different for each solution, not to mention if there is a desire to test the tests in your environment, you will have to copy and paste pieces of code.

Therefore, the idea arose to write our own simple mechanism for testing the speed of various operations. The idea seemed interesting, so the start was made!

Goals

We should start by setting goals for the future tool. I wanted to see the project as a universal tool for testing the speed of anything. But after thinking over the details and mistakes of the past , it was decided to start small.

So, it was necessary to get a tool that:
')

• compares the speed of various functions
• has the ability to use pre-prepared tests
• displays the result in a readable form
• has the ability to create your own tests and options for presenting results
• can be easily used on other platforms

Measurement mechanism

To measure the execution time of the function, it was decided to use a similar, method

protected function getTime($time = false) { return $time === false? microtime(true) : microtime(true) - $time; } 

The principle of operation is simple, if a call occurs without parameters, then we return the current state of time, if the call occurs with the time parameter, then the difference between the current time and the transmitted time is returned.

But where there is the calculation of time, there is also the amount of memory consumed, so later a similar method of measuring consumed memory was added.

 protected function getMemory($memory = false) { return $memory === false? memory_get_usage() : memory_get_usage() - $memory; } 

The mechanism is similar to the mechanics of time measurement, only in this case the value of the allocated memory is transferred to the script.

As you know, some functions behave differently depending on the input data set, therefore, in each test, an array of input data is defined for the testing functions. To obtain the most accurate results, functions are tested on each set several times. Among other things, testing is carried out in different sequences.

During the experiments, it was noted that the amount of free memory before each test is different, although for most tests it was insignificant, but for the order I would like to have conditions that are the same for all tests or close to those. Therefore, it was decided to store the results in the local SQLite repository, and before starting the tests, do one verification test for filling variables with data.

In order to be able to create your own options for presenting results and your own test options, 2 abstraction models have been created. Model test (Test), contains all the information about the test, including test functions. The DataViwer model contains methods for converting test results to a readable form. For convenient output of views, the Twig template engine was used and the bootstrap style library was connected, and a HighCharts viewer was also created.

As a result, the general mechanism of such work. The functions necessary for comparison are taken and run on execution with different data sets and in different sequences. When this occurs, the time of each execution is measured and the result is recorded in the repository. The test model (Test) is responsible for this stage. After all measurements, the results are transferred to the data view (DataViwer), where information is processed and output.

Implementation of testing

Test class

A simple example of the implementation of the test class, on the example of testing the speed of the operation before the increment and post increment.


The class must inherit the abstract class TestAbstract , which contains the basic mechanics of working with data streams.

$ name - sets the name of the test that can be used when outputting to the DataViewer.

$ valueTest is the sample size of the test, an array of values, with each of which a function will be executed for testing. Thus, each tested function must necessarily take one parameter. It will be a number, string or array is not important, it all depends on the specific case. In our example, there are enough numbers that will indicate the volume of operations performed with an increment.

$ qntTest - tells how many times each sample size will be tested.

$ viewers - an array of data views that will be generated when rendering a report. In fact, this is a set of fully qualified class names that inherit the abstract ViewrAbstract class. Pre-prepared viewers are rendered in TestCore class constants.

$ functions - an array of names of functions that will be used in testing. The keys of the array are the names that will be displayed in the results.

$ strategy is an array of testing strategies; each strategy must be represented by an array with a sequence of function names. In the example, 2 strategies are indicated - direct sequence and in reverse.

The functions themselves, which, as mentioned above, should take one value. In our example, we consider this the number of incremental series operations performed.

As a result, we get a series of tests where each testing strategy will be tested 5 times with each sample size ([100, 1000, 2000, 3000]).

Presentation class

Now let's take a closer look at a simple data presentation class.


The class implements the abstract class ViewerAbstract .

$ view - contains the name of the view, which by default should be in the folder / views / viewers

function generateData ($ data) is a method for processing an array of test results. The result will be transferred to the default data parameter in the specified view.

function run ($ data) is an optional method for the implementation, but if it is necessary to change the path to the data representation, then it should be redefined.

public static function model ($ class = __CLASS__) - method for supporting static method calls

Use cases

To use the testing functionality, 2 main methods were created.

Test run method

 function test($test, $params = [], $onlyData = false) 

$ test - the full name of the test being run. They can be used as their test variants or in advance prepared.

$ params - an array of parameters to run the test. With this parameter you can point test parameters.

$ onlyData - the parameter responsible for displaying the result set or a rendered view.

Function comparison method

Method of comparing user functions without creating additional classes

 function compare($func = [], $params = [], $onlyData = false) 

$ func is an array of anonymous functions, where the keys of the array are the names of the functions in the test results.

$ params - an array of test parameters, similar to the parameters of the test method.

$ onlyData is also similar to the test method parameter, and is responsible for the output option.

Work examples

The easiest and fastest use case is to use a prepared test. All prepared tests are rendered into constants of the Speedy class.

 print Speedy::test(Speedy::PHP_SOF_VS_COUNT); 

To compare user-defined functions, you must create anonymous functions and call the Speedy :: compare method

Test results

Test results for the moment can be displayed by 4 views.

VIEWER_TLIST

Tabular listing of all time measurements taken. In essence, this is the output of all records from the repository, without any transformations. The data set contains information about the name of the function being tested, the elapsed time, the sample size, the used memory size, the batch number in which the test and comment were performed. The comment indicates within which strategy the test of this function was performed.

VIEWER_TGROUP

Presentation in tabular form in the form of grouped data on the test batch (by the pass number of the strategy), i.e. in one line will be the results of testing functions that were carried out in the framework of a single strategy and in one test run.

The columns of the table will display data on the sample size, runtime, percentage of speed from the worst result, memory wasted, comment, and the name of the function that became the winner in time among the current pass. Separately, I would like to clarify the percentage column. This value is calculated as a percentage, by how much time the function outpaced the execution of the slowest function. If the value is not set, then this function is an outsider in the pass according to the execution time.

VIEWER_TAVG

Presentation in tabular form in the form of averaged indicators for the sample size, i.e. in one line will be the average indicators of testing functions for one sample.

The columns provide information on the number of victories of the function in the sample, the average time percentage of victories, the name of the winning function. Functions winner is determined by the number of wins in the sample.

VIEWER_GBUBLE

Representation in graphical form as a set of points, each of which corresponds to a time value and a sample size. This view is implemented using HighCharts charts.

Results

To summarize it would be desirable that the goals have been achieved. But of course there is still work to do. The plans include working on exception handling, adding the ability to change the settings for a set of columns, as well as the ability to set your own column names, an increase in the number of tests. I would also like to add the ability to conveniently test the speed of working with databases.

The source code of the project can be viewed here.

PS : This project is being developed in the framework of personal interest in this topic and does not claim to be the best of its kind. I would be glad if someone likes and will be useful this work. Constructive criticism and advice are welcome.