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 :)
