Ask Your Question
0

OpenCV 3.0 Vs OpenCV 2.4.9 + Sobel Performance

asked 2015-08-01 07:55:10 -0500

updated 2015-08-02 03:13:54 -0500

I'm experiencing a very performance differences between 2.4.9 and 3.0.

With the simple Soble function I see OpenCV 3.0 run 10x slower than OpenCV 2.4.9 ... O_O ...

I've build up a Visual Studio 2013 project self contained with my benchmark.

Could anyone try and tell me if It sees the same performance difference and could someone explain me the reason?

The project could be downloaded at: http://www.versionestabile.it/opencv/...

With @Eduardo, @StevenPuttemans we ended up to note that OpenCV 3.0 Sobel First Call has a very big overhead, right near 700msec.

cout << "Hello, World! " << CV_VERSION;

int64 A, B;
A = getTickCount();

string _image_name = "equalizzata300.bmp";
string _image_path = "../img/";
Mat image;
image = imread(_image_path + _image_name, CV_8UC3);

if (!image.data)
{
    cout << "Could not open or find the image" << std::endl;
    return;
}

int scale = 1;
int delta = 0;
int ddepth = CV_16S;

Mat grad;

int64 a, b;

std::cout << "\n STD SOBEL STARTED 1ST CALL \n";
a = getTickCount();
Sobel(image, grad, ddepth, 1, 1, 5, scale, delta, BORDER_DEFAULT);
b = getTickCount();
convertScaleAbs(grad, grad);
B = getTickCount();
cout << "\n STD SOBEL FINISHED 1ST CALL in " << 1000 * (((double)(b - a)) / getTickFrequency()) << ", total " << 1000 * (((double)(B - A)) / getTickFrequency());

std::cout << "\n STD SOBEL STARTED 2ND CALL \n";
a = getTickCount();
Sobel(image, grad, ddepth, 1, 1, 5, scale, delta, BORDER_DEFAULT);
b = getTickCount();
convertScaleAbs(grad, grad);
B = getTickCount();
cout << "\n STD SOBEL FINISHED 2ND CALL in " << 1000 * (((double)(b - a)) / getTickFrequency()) << ", total " << 1000 * (((double)(B - A)) / getTickFrequency());

namedWindow("Sobel", CV_WINDOW_AUTOSIZE);
imshow("Sobel", grad);
waitKey(0);

The question now is: Does someone know the reason of that? Is that true also for other image processing functions?

edit retag flag offensive close merge delete

Comments

61mb for a simple sobel test ? please remove the pdb ndb files from it. or rather even restrict it to the src code. folks won't have your vs version, or opencv on the same path.

berak gravatar imageberak ( 2015-08-01 08:06:56 -0500 )edit

much simpler test (running on ubuntu):

Mat r(500, 500, CV_32F);
randu(r, 0, 1);

int64 t0 = cv::getTickCount();
for (int i=0; i<10000; i++)
{
    Mat s;
    Sobel(r,s,-1,1,0);
}
int64 t1 = cv::getTickCount();

cerr << CV_MAJOR_VERSION << " : " << ((t1-t0)/getTickFrequency()) << endl;

2 : 2.97818

3 : 3.16783

berak gravatar imageberak ( 2015-08-01 08:13:44 -0500 )edit

There are no pdb files. Only src and dll and lib used :) It's the world300.dll that take the most of the space. Have you looked at the zip?! :/

I've put all the dll I've used right because you could try my dll!

shadowsheep gravatar imageshadowsheep ( 2015-08-01 08:26:25 -0500 )edit

well, above shows a performance loss of 3%, not 10x.

no, i did not look at yor zip, it's too large, and i probably can't use your binaries anyway.

just make a gist with the src code, maybe.

berak gravatar imageberak ( 2015-08-01 08:31:45 -0500 )edit

Yep, so if you wanna try the src with the attach image we could check the performance on your system.

shadowsheep gravatar imageshadowsheep ( 2015-08-01 08:34:00 -0500 )edit

My results:

2.4.10 : 2.52688
3.0.0-rc1 : 2.94135

Yes, there is a little decrease on performance but not of a factor 10.

You should try the berak code, in your test code you benchmark only on iteration.

However, I tried your code (VS2010, release, win32 mode) with one iteration:

Hello, World!
CV_VERSION=2.4.9
 STD SOBEL STARTED
 STD SOBEL FINISHED in 33.851, total 56.6165
Hello, World!
CV_VERSION=3.0.0
 STD SOBEL STARTED
 STD SOBEL FINISHED in 708.196, total 734.515

with 100 iterations on Sobel function:

Hello, World!
CV_VERSION=2.4.9
 STD SOBEL STARTED
 STD SOBEL FINISHED in 2105.58, total 2128.75
Hello, World!
CV_VERSION=3.0.0
 STD SOBEL STARTED
 STD SOBEL FINISHED in 2902.04, total 2928.78
Eduardo gravatar imageEduardo ( 2015-08-01 10:28:35 -0500 )edit

@Eduardo, that is quite a nice comparison, however this does mean that people who need the process on a single input image will have the downsides of the new backend ...

StevenPuttemans gravatar imageStevenPuttemans ( 2015-08-01 12:33:43 -0500 )edit

@Eduardo, thanks to have given it a try. So, like StevenPuttemans says, it seems like OpenCV 3.0 have a first function call overhead.

I've so made a new test with only two calls that seems to enforce that assumption.

I've put the code in the question.

Hello, World! 2.4.9

STD SOBEL STARTED 1ST CALL

STD SOBEL FINISHED 1ST CALL in 22.2636, total 45.8063 STD SOBEL STARTED 2ND CALL

STD SOBEL FINISHED 2ND CALL in 23.4234, total 86.663

Hello, World! 3.0.0

STD SOBEL STARTED 1ST CALL

STD SOBEL FINISHED 1ST CALL in 426.064, total 438.489 STD SOBEL STARTED 2ND CALL

STD SOBEL FINISHED 2ND CALL in 22.0421, total 469.745

shadowsheep gravatar imageshadowsheep ( 2015-08-02 03:08:23 -0500 )edit

@matman: Good point ! Yes it solved it. With one iteration:

Hello, World!
CV_VERSION=3.0.0
 STD SOBEL STARTED
 STD SOBEL FINISHED in 22.3572, total 34.8384

With 100 iterations:

Hello, World!
CV_VERSION=3.0.0
 STD SOBEL STARTED
 STD SOBEL FINISHED in 2050.49, total 2063.95
Eduardo gravatar imageEduardo ( 2015-08-02 09:16:36 -0500 )edit

@matman: Yep! It works!

    Hello, World! 3.0.0
 STD SOBEL STARTED 1ST CALL

 STD SOBEL FINISHED 1ST CALL in 20.2502, total 39.5455
 STD SOBEL STARTED 2ND CALL

 STD SOBEL FINISHED 2ND CALL in 20.683, total 67.209

So @matman if you wanna answer this question, I'll mark it like "solved" because in fact it solves it! Thanks to all.

Perhaps that's strange, it's like OpenCV 3.0 setup OpenCL driver (like GPU module) even if I don't ask them to use it.

Thank you all and see you at the next question.

shadowsheep gravatar imageshadowsheep ( 2015-08-02 11:20:51 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
3

answered 2015-08-02 08:36:57 -0500

matman gravatar image

In relation to the first call overhead can you test if it helps if you add the following in your code #include <opencv2/core/ocl.hpp> and then cv::ocl::setUseOpenCL(false); at the begining.

Yes I know that you are using cv::Mat and not cv::UMat, but I observed a similar behavior in my Code even if I use cv::Mat.

edit flag offensive delete link more

Comments

By the way, another solution might be to disable the OpenCL dynamic loader by building OpenCV with cmake -DHAVE_OPENCL_STATIC=ON -DOPENCL_LIBRARY=... -DOPENCL_INCLUDE_DIR=.... This will ensure that OpenCL is only called if you explicitly call and OpenCL function from the ocl class.

StevenPuttemans gravatar imageStevenPuttemans ( 2015-08-03 10:33:42 -0500 )edit
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2015-08-01 07:55:10 -0500

Seen: 2,390 times

Last updated: Aug 02 '15