Consider adopting OpenCV - need memory pools/custom allocator

asked 2019-04-09 11:35:40 -0500

kzuiderveld gravatar image

Hello,

During the past year, I worked on cleanup and speed optimization of a moderately large non-OpenCV codebase; I accomplished roughly two orders of magnitude performance improvement. Aside from optimizing compute-intensive code (using algorithm rewrites and AVX2 optimizations), the biggest speedups were obtained using 1) reference counting images and 2) using memory pools.

Memory pooling is essential to obtain performance; with 30+ threads being active, allocation of images using a memory pool is essential to obtain good performance.

As there is quite some overlap in functionality between our codebase and OpenCV, it might be viable to refactor our codebase to become a layer "around OpenCV" and rely on OpenCV to provide most of the functionality. That represent a major refactoring effort - but it is only a viable solution if OpenCV supports memory pooling (or custom allocators in the mat class that actually work correctly).

I tried to find answers to the question "does OpenCV support custom allocators/memory pools", but the few posts I encountered probably don't apply anymore as the API has changed.

Can somebody please pitch in and let me know whether mat custom allocators/memory pools are supported?

Secondly, memory bandwidth now limits the throughput of our implementation. I presume that an OpenCV pipeline would have exactly the same issues. There's a possible solution for this: implement algorithms using cache blocking, possibly using hundreds of co-routines (a C++20 feature). Any folks that would be interested in developing this approach within the OpenCV framework?

Thanks, Karel

edit retag flag offensive close merge delete

Comments

You may want to look directly into the OpenCV source code.

It is only possible to provide a pointer to a user allocated memory to a cv::mat as far as I know. Could be related: custom deallocator #14178.

Eduardo gravatar imageEduardo ( 2019-04-10 10:07:22 -0500 )edit