How in Android Studio to test a piece of code at the time of passage?

Better later than never. The question is quite simple at first glance, and it can be solved in different ways. After reading a number of articles, tests from various sources, mostly official ones, I solved this problem in the following way:

I covered parts of the JUnitPerf code . It has a couple of wrappers for the duration of the passage, in case of deviation, we deduce what is needed. And this is what I was looking for.

But the question was formulated differently, for this I emulated several situations and made my test: first I used different databases (it was interesting), later I simplified and used various collection interfaces and wrote down and deleted a small number of records, or rather 100.000, as it turned out later, this is a very good number, but not the essence. I already knew that it was necessary to use two native methods of the system at the root, but we will go back a bit, why it is impossible to measure this way ?:

DateFormat.getDateTimeInstance().format(new Date()) 

I think many people know or guess, but in short - there are a lot of unnecessary actions starting from the date styles, creating an object, then we need to somehow measure the entry and exit points - autoboxing etc, all this will create a huge error, and as a result a strong variation when measuring one the same operation. But even if everything is removed and done like this:

 Date date = new Date(); 

Even so badly, we spend time on creating an object of a class, and its internal implementation, we look inside and see

 public Date() { this(System.currentTimeMillis()); } 

We are more than satisfied with it, so as not to produce instances of the class. This is one of the methods; second, let's write them down together, through a call, to make it easier to read:

 System.currentTimeMillis(); System.nanoTime(); 

Returns long, the second more accurate (detailed), in nanoseconds. We read the documentation and see it in nanoTime ():

It is a timestamp on the same device.

There are nuances, but the essence of the documentation there everything is obvious: nanoTime and next currentTimeMillis

After that you can finish, but back to the test. There is a lot of information that the error can be estimated at 10-15ms depending on the situations (let me remind you of these two approaches), I would like to refute this, but .... I made a huge number of test starts with different parameters with different devices, I took into account many factors, wrote down the values ​​only after allocating the memory, took into account the record number, I had an algorithm for calculating the average value and still sooooo many nuances, and the strongest scatter was:

 System.nanoTime(); //374-412мс System.currentTimeMillis(); //386-439мс 

This is an individual case, and most likely an error in the measurements, but this is a fact. Perhaps if you increase the number of records in the N number of everything and would be reduced to min, but I wrote that it was the strongest variation. On average, it was just 10-15ms, but sometimes sometimes, as in the example above, there was another result.

In summary, the answer is:

  long startTime = System.nanoTime(); // ... the code being measured ... long estimatedTime = System.nanoTime() - startTime; 

The most accurate way to measure a piece of code, on one of the devices I found.