Permalink
Reply
I have been working on DCV for some time to make it GC-free. GC is good. However, people have a prejudice against GC, especially if computer vision is in question. You may probably ask if any performance improvement has been gained. I don't know at the moment; with some limited tests (for instance, convolution), there is no difference, I would say. I tested most of the things in video loops to detect memory leaks, and I believe we don't have any. For the rest, I will copy and paste some of the below information from the GitHub page https://github.com/libmir/dcv.
-
In the new API, all functions accept slice shells as Slice!(T*, N) as input. On the other hand, API functions return RC-allocated Slice!(RCI!T, N). In this way, ref-counted slices can be passed to API functions like input.lightScope. It is recommended to avoid using lightScope in loop bodies; instead, create a lightScope outside of the loop body before using it. It has a cost.
-
nogc capabilities of mir libraries and dplug:core are utilized when needed.
-
ThreadPool of dplug:core is used in the entire library for parallelism.
-
class Image and class Figure use manual memory management. A call of function destroyFigures deallocates all allocated figures automatically. If an Image instance is initialized with non-null ubyte[] data, this time, the Image instance behaves like a slice shell, and it does not attempt to deallocate the borrowed data slice.
-
All examples are up-to-date. Please refer to the examples instead of the docs at the moment.
-
There may be bugs in the library. We need more people to test for bugs. The docs and unittests are outdated.
Please give it a try and destroy me :)
