0

I'm doing some performance tests of my C++ program(on Linux 64bit) using Tracy profiler and I have seen a result which I can't justify in my mind. The code snippet that I measure is:

void doWork() {
    MyObj obj;
    while(m_channel.try_dequeue(obj) {
        report(obj);
    }
}

inline void report(const MyObj& obj) {
    ZoneScoped;
}

Below you can see the measurements of the report() function (it is near-empty) graphically.

enter image description here

There are 63 report() calls. Each of them took small amount of time and 1 report() call which took big amount of time relative the previous 63 calls.There are periodical peeks as seen the graph.
I thought it is related to the ZoneScoped macro. In order to eliminate its effect, I have implemented a simple time measurement utility which just puts a timestamp to a queue. But the result is still the same.

I can't understand the reason of these peeks. Any idea is appreciated.

There is no other programs running in the Linux box at the time of testing.

xyzt
  • 1,201
  • 4
  • 18
  • 44
  • 1
    The image is not very helpful. Can you show the data in non-image form? – dshin Jan 23 '22 at 20:01
  • There are other thing going on in the computer that might interfere with the runs. "Periodical peeks" makes me think about timer interrupts. – BoP Jan 23 '22 at 20:07
  • 1
    1. Profilers should be used to locate bottle necks in the code not to measure performance. 2. For performance measurement you can use google benchmark. 3. Calling empty function should do nothing. C and C++ has "As-if rule" so if compiler optimizations are enabled such function should be just removed by optimizer. 3 Please provide [mcve], taking about performance code which is so reduced is pointless.Performance measurements are hard and full of crafty traps. It is easy to measure something which do not reflect actual problem, that is why providing full example is important. – Marek R Jan 23 '22 at 20:08

1 Answers1

0

It looks like it is a multithreaded app which is exposed to the threads context switching, starvations or contentions which by nature is indeterministic as other threads may do different stuff each time you measure the app. Also the queue itself may have different number of elements inside each time you measure. I would ensure that the conditions in each run are the same by using some kind of mocking. Please note that it is very unlikely that there are no other programs run in the background even you haven't run them explicitly (could be some daemons, etc.)

tomaszmi
  • 443
  • 2
  • 6