I have 2 examples of how I was planning to call functions. 1 example is the function that just creates the mat. I changed the name to %mat instead of %cv-mat so it would match OpenCV's Mat class name better. The other example, add, I provide because it is an example of a function that would accept a mat as a parameter, I use add here as an example of all functions that would accept either my garbarge collected verion or my non garbage collected.

I plan to provide both so, if you absolutely need to, you can get a speed increase. Also fnalizers seem to be twice as slow as manual memory management and 4 times slower than with-* macros, and I was advised by my tutor to include all 3 forms of MM.  All of the functions to create the %mat and %mat-expr type are written correctly for both. I was hoping you can give me a thumbs up on if the 2 examples are good, so I can go ahead and write all of my finalizers for all of my types.


Example 1:

;; Mat::Mat()
;; Mat* cv_create_Mat()
(defcfun ("cv_create_Mat" %mat) %mat
  "MAT constructor")

;; Mat::Mat()
;; Mat* cv_create_Mat()
(defcfun ("cv_create_Mat" %%mat) (%mat :garbage-collect t))


(defun mat (&rest args)
  (cond ((eq (first args) nil) (%mat))
    ((eq :t (car args)) (%%mat))
    (t nil)))


Example 2:

;; MatExpr + operator
;; MatExpr* cv_Mat_add(Mat* m1, Mat* m2)
(defcfun ("cv_Mat_add" %add) (:pointer mat-expr)
  (m1 %mat)
  (m2 %mat))

;; MatExpr + operator
;; MatExpr* cv_Mat_add(Mat* m1, Mat* m2)
(defcfun ("cv_Mat_add" %%add) (%mat-expr :garbage-collect t)
  (m1 %mat)
  (m2 %mat))



(defun add (&rest args)
  (cond ((eq :t (last args)) (%%add (first args) (second args)))
           (t (%add (first args) (second args)))))



Btw you asked what my motivation for writing an OpenCV wrapper was and it's because of these 4 reasons:

1. The libraries that exist are wrappers for the deprecated C OpenCV interface,  mine is for the consistently updated C++ interface

2: They are incomplete, mine is 3 times bigger or more than the two that exist now , and it aims to be complete within 3 months max

3. Mine is aiming for inclusion in OpenCV proper, a generator is being built that will automatically generate all of my low-level functions/types/constants when OpenCV is built...so it will always be up to date

4: I'm helping the C wrappers for the C++ interface that this library binds to so I will be at the forefront of the knowledge needed to keep this library, supported and revolutionary as the first complete Lisp computer vision library

On Saturday, April 26, 2014 5:55 AM, Joeish W <joeish80829@yahoo.com> wrote:

Some new exciting information...I ran the create-mat function a million times and my memory went up a slight bit,  I ran a million more and it went up a gain..I ran a million more and it actually leveled off. After running a million more times it actually started going down.  I was able to see the Lisp GC at work...It doesn't seem to kick in until memory becomes an issue, again sir ...it was an honor

On Saturday, April 26, 2014 4:24 AM, Willem Rein Oudshoorn <woudshoo@xs4all.nl> wrote:

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


_______________________________________________
Cffi-devel mailing list
Cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel