Why is threading slowing down over time?

asked 2018-07-17 09:18:04 -0500

Crigges gravatar image

updated 2018-07-17 09:22:51 -0500

If I run the following sample code the calls getting slower and slower:

#include "opencv2\opencv.hpp"
#include <vector>
#include <chrono>
#include <thread>

using namespace cv;
using namespace std;
using namespace std::chrono;

void blurSlowdown(void*) {
    Mat m1(360, 640, CV_8UC3);
    Mat m2(360, 640, CV_8UC3);
    medianBlur(m1, m2, 3);

int main()
    for (;;) {
        high_resolution_clock::time_point start = high_resolution_clock::now();

        for (int k = 0; k < 100; k++) {
            thread t(blurSlowdown, nullptr);

        high_resolution_clock::time_point end = high_resolution_clock::now();
        cout << duration_cast<microseconds>(end - start).count() << endl;

Why does that happen? Is it a bug?

Some observations / remarks:
-The effect is amplified when using the debug Library, even if no debugger is used
-The processor boost clock is stable and is not causing the problem
-It does not matter if m1 and m2 are allocated on the heap instead of the stack
-The slowdown effect does not appear when medianBlur isn't called

My system:
-Windows 10 64bit
-MSVC compiler
-Newest offical OpenCV 3.4.2 binaries

edit retag flag offensive close merge delete


I think you used the number of threads so much. Did you try with k=4,8 ?? (Depend on your CPU)

hoang anh tuan gravatar imagehoang anh tuan ( 2018-07-17 21:22:26 -0500 )edit

The are only 2 threads active at the same time. thread t is getting destroyed after each loop.

Crigges gravatar imageCrigges ( 2018-07-17 22:57:37 -0500 )edit

@Tycos, please avoid using your own multithreading with opencv. a lot of functions are explicitly not thread-safe.

rather rebuild the opencv libs with TBB or openmp support.

(and debug builds have most optimizations off, so, no wonder it's slow)

berak gravatar imageberak ( 2018-07-18 01:03:07 -0500 )edit

@berak this is not the problem. First only one thread is interfering with any cv context at the same time. Second the performance is good but it is getting worse and worse over time. Third opencv is mostly thread safe and wants you to use multithreading: http://answers.opencv.org/question/69...

Crigges gravatar imageCrigges ( 2018-07-18 03:21:19 -0500 )edit

that is about internal parallelism. again, imho, you're on the wrong path here.

berak gravatar imageberak ( 2018-07-18 03:40:52 -0500 )edit

"OpenCV philosophy here is that application should be multi-threaded, not OpenCV functions." - http://answers.opencv.org/question/69...

Crigges gravatar imageCrigges ( 2018-07-18 05:33:49 -0500 )edit

sorry dear, but you misread all of it.

OpenCV philosophy here is that application should be multi-threaded, not OpenCV functions

it says the opposite.

berak gravatar imageberak ( 2018-07-18 05:42:13 -0500 )edit

I don't think so. From the context I clearly understand that internal parallelism (TBB) is only supported in a "may be a dozen" functions yet because OpenCV philosophy is that application should use multiple thread on their own to call the functions instead.

Crigges gravatar imageCrigges ( 2018-07-18 06:17:43 -0500 )edit

definitively not so.

berak gravatar imageberak ( 2018-07-18 06:19:32 -0500 )edit

So can you explain me what Iam getting wrong?

Crigges gravatar imageCrigges ( 2018-07-18 06:24:08 -0500 )edit