very slow cv::findContours when using in loop (Bug #1424)

Added by Hagen Borstell over 13 years ago. Updated over 10 years ago.

Status:Done Start date:
Priority:High Due date:
Assignee:Vadim Pisarevsky % Done:

0%
Category:imgproc, video
Target version:2.4.0
Affected version: Operating System:
Difficulty: HW Platform:
Pull request:

Description

Hello,

I don't know if it is a defect, but the following 'bug' makes all slow:

In opencv c++ Interface the function cv::Findcontours(...) saves the found contours in a data field of type vector<vector<Point>>.

On my computer that interface makes the computation 10x slower when found 5000-10000 contours (compared to c interface) - i think because of deconstructing the vectors, example:

1cv::Mat image;
2vector<vector<Point>> contours;
3while (do)
4{
5   contours.clear();
6   cv::findContours(image, contours, ....);
7   ...
8}
contours.clear() takes a lot of time.
if i dont't use .clear command, then memory leaks arise.

Question: I think for now "looped" contour analysis it is better to use c interface or could one expect an optimized c++ variant someday.

History

#1
Updated by vasile v over 13 years ago

STL vectors are known to be slow because of the many alloc/dealloc commands. If you want max performance of your app, use the C api.

However, please make sure your application runs in Release mode.

In debug mode, a lot of DEBUG_ASSERTs checking for out-of-bound accesses make the STL vectors extremely slow. In release mode, they perform acceptably well.

#2
Updated by Hagen Borstell almost 13 years ago

I have evaluated both variants (FindContours in C vs. C++) in a project for detection of markers over more than one camera in realtime (>> 1Hz). Both systems now run for several month. For contour analysis, it seems that only the c-interface works well (fast), because the c++-Interface is to slow (because of the vectors). That is still true in Release mode (it is faster than debug but always a lot slower than the C-Interface in Release Mode).

But otherwise, OpenCV is a fantastic library with more and more fantastic and fast features:)

Thank very much.

#3
Updated by Marina Kolpakova almost 13 years ago

  • Description changed from Hello, I don't know if it is a defect, but the following 'bug' m... to Hello, I don't know if it is a defect, but the following 'bug' m... More

#4
Updated by Marina Kolpakova almost 13 years ago

It seems that issue is already resolved. So I'm closing the ticket.

  • Status changed from Open to Done
  • Target version set to 2.4.0

#5
Updated by Kim Ngo over 10 years ago

Hi,

I noticed there was a performance issue dealing with the vector<vector<Point> >. Is there a particular reason to use the STL vector instead of an array if we already have a predetermined size? If not, would it be feasible to change the underlying data structure to an array in order to increase performance by eliminating vector push_backs that may require multiple memory allocations?

Thanks

Hagen Borstell wrote:

Hello,

I don't know if it is a defect, but the following 'bug' makes all slow:

In opencv c++ Interface the function cv::Findcontours(...) saves the found contours in a data field of type vector<vector<Point>>.

On my computer that interface makes the computation 10x slower when found 5000-10000 contours (compared to c interface) - i think because of deconstructing the vectors, example:

[...]

contours.clear() takes a lot of time.
if i dont't use .clear command, then memory leaks arise.

Question: I think for now "looped" contour analysis it is better to use c interface or could one expect an optimized c++ variant someday.

Also available in: Atom PDF