Joeish W joeish80829@yahoo.com writes:
(defcfun ("cv_create_Mat" create-mat) (%cv-mat :garbage-collect t))
a million times to bench mark it it was actually 4 times slower than my original code....I really do need this all to be fast code, since computer vision can benefit from the speed. Also I noticed when I ran the (create-mat) function 1,000,000 times my ram went up a tiny bit and didn't go down..Is that normal for finalizers.
Well, that it is a bit slower is not really surprising because:
1. CLOS classes are instantatied to wrap the pointer 2. The trivial garbage needs to keep track of the objects 3. The conversion code is done by generic functions.
However, this is solvable. But I really would not focus on this right now. I cannot really imagine that creating the matrix is the bottleneck.
With respect to the memory, as long as it does not grow indefinitely I would not worry about it. The trivial garbage package might introduce some memory overhead which is not directly reclaimed by the garbage collector.
When I use with-* macros or manual MM I don't get an increase in ram on my system. I would like to include finalizers in my library but is there any way to overcome these obstacles to make that happen...Again the time you took to help me on this is much appreciated. :)You really helped me to understand.
Using `with-*` macros is a good idea. Inside these macros you can do the manual garbage collection and avoid maybe the generic type conversion. But to make it robust the `with-*` macros will not (I expect) be faster than the code you have now.
Making the code fast is certainly doable and not hard, but you should first make it work and figure what needs to be fast and which conveniences you are willing to give up for the speed improvement.
Wim Oudshoorn